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VIRTUALI ZED MULTIMEDIA CONNECTION SYSTEM 
Background of the Invention 
The invention relates generally to multimedia 
5 connection systems. 

With few exceptions, systems supporting facilities 
for the sharing of live audio and motion-video images 
have provided integrated hardware platforms that 
contained both video encoding/decoding devices and an 

10 Integrated Services Digital Network Basic Rate Interface 
(ISDN/BRI) . Stand-alone, dedicated video conferencing 
systems began as wholly proprietary designs (early video 
conferencing systems from PictureTel Corporation and 
Compression Laboratories, Inc.)/ but by 1993, 

is conferencing products based on the personal computer 

became available. These systems relied upon standardized 
operating systems to host command, control, and user 
interface software components. Specialized hardware 
support for videoconferencing services was implemented in 

20 adapter board configurations that contained real-time 
video processing facilities, integrated with an ISDN/BRI 
hardware component (PictureTel S1000, CLI Eclipse) . For 
all intents and purposes, the software architectures used 
in the implementation of the motion-video connectivity 

25 sub-systems have been extremely tenuous, and essentially 
unusable as discreet modular components in that they 
lacked a comprehensive, extensible software model to 
support the diversity of underlying hardware 
technologies . 

30 Perhaps the best attempt at creating a simple, 

reusable motion-video connectivity sub-system for 
integration into second-party products is available from 
Zydacron, Inc. (Zydacron Z240, Z250) . Even the simple, 
clean implementation of this system's software control 

35 mechanism requires many months of specialized software 
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development, including significant design and 
implementation of complicated protocol components, before 
the sub-system is usable in a commercial product. 

ITU-T RECOMMENDATION H.320 

5 Motion-video connectivity, between systems from 

different vendors, is possible only through the general 
acceptance of standardized protocols for interconnection 
between local and remote stations. In March of 1993, the 
International Telecommunication Union (ITU-T) adopted 

10 Recommendation H.221 (LINE TRANSMISSION OF NON— TELEPHONE 
SIGNALS) as the standard for the interconnection of 
devices supporting the exchange of audio, video, and 
binary data types (see ITU-T Recommendation H.221, FRAME 
STRUCTURE FOR A 64 TO 1920 kbits/s CHANNEL IN AUDIOVISUAL 

15 TELES ERVICES , 1994. This protocol is grouped with two 

other related interconnection protocols under the rubric 
of Recommendation H.320, which is now the generally 
accepted set of protocols for implementing composite 
audio/motion-video /data connectivity across the 

20 Integrated Services Digital Network as embodied in 

narrow-band visual telephone systems ISDN- see, ITU-T 
Recommendation H.320, NARROW-BAND VISUAL TELEPHONE 
SYSTEMS AND TERMINAL EQUIPMENT, 1994) . Recommendation 
H.320 is a virtualized definition of an extensible, 

25 finite set of capabilities, device modes, data transfer 
frame structures, and call control procedures. At some 
level in the software layers that comprise H.320- 
compliant connectivity stations, there must be (by 
definition) an implementation of a significant subset of 

30 the Recommendation H.320 multimedia interconnection 

services. Despite this distinct commonality shared by 
inter-connectable stations, there are no commercially 
available software models, known to this author, that 
promote these standardized audiovisual/data connectivity 
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services to a useful, consistent, reusable kernel of 
device-independent software control elements. 

SYSTEM ARCHITECTURES 

System and user interface software designs for 
5 multimedia connectivity stations have typically been 
derived directly from the service profile of the 
underlying devices that they control — multimedia 
connectivity software architectures are mostly hardware 
driven. Since multimedia connectivity tasks, such as 
10 videoconferencing, require synchronous encoding/ decoding 
of audio and video data at high data rates emanating 
to/ from synchronous data transfer connectivity devices, 
most of the motion-video connectivity devices integrate 
all the necessary components onto one large, multi- 
is purpose device. Typically these devices take the form of 
an ISA or EISA personal computer adapter that includes 
additional hardware support for specialized video overlay 
functions. without a major software development effort, 
it is impossible to utilize the manufacturer's sub-system 
20 for a new connectivity application. Those wishing to 

impart videoconferencing services to their enterprise are 
most frequently restricted to the single software 
application program provided by the hardware vendor; that 
is the only one capable of sufficiently driving the 
25 vendor's complicated hardware configurations. PictureTel 
Corporation, Zydacron, Inc., and Compression Labs, Inc., 
design and develop most of the world's motion-video 
connectivity sub-systems according to this multiple 
integrated device architecture. These systems perform 
30 well for stand-alone videoconferencing purposes. Recent 
attempts by Intel Corporation to produce software video 
solutions with minimal hardware support, are of inferior 
image and sound quality. The allocation of valuable 
central processing unit resources to real-time video 
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encoding/ decoding tasks is inefficient at 128 kbit/s data 
transfer rates, and entirely inappropriate at transfer 
rates of 384 kbit/s, or more. A data transfer rate of 
384 kbit/s is required to produce motion-video connection 
5 services with frame rates and image clarity sufficient 
for large-scale acceptance of these technologies; a 128 
kbit/s data transfer rate produces video image quality 
that can best be described as "disappointing 11 to 
uninitiated technology customers who typically expect a 

10 broadcast quality television image (see D. Minoli and R. 
Keinath, Distributed Multimedia Through Broadband 
Communications Services, Norwood, Massachusetts, Artech 
House, pp. 187-207, 1994). There will likely continue to 
be a continuous stream of hardware and software solutions 

is to improve the quality of motion-video connectivity using 
personal computers, and systems will continue to undergo 
rapid change as high-bandwidth ISDN connections become 
cost effective and generally available. In consideration 
of the extraordinary engineering effort required to 

20 produce motion-video connectivity systems, and the 
difficulties of developing software to support new 
devices, more can be done to reuse the high-level 
applications and protocol support code developed for 
these products. 

25 ^W ar Y of the I nvention 

VIRTUAI«IZED SYSTEM DESIGNS 

An analogous problem to that of the hardware- 
driven software designs in multimedia connection systems 
can be found in the early attempts to create Graphical 

30 User Interfaces for the wide variety of graphics hardware 
used with personal computers. Here again, hardware 
features influenced overlaying software designs, with a 
proprietary device driver interface supported by almost 
every distinct video graphics adapter manufacturer. The 
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Microsoft: Windows Operating Environment, and the 
Operating System/ 2 Presentation Manager, solved the 
problems related to video graphics hardware variability 
by abstracting the services of these devices to a fully 
5 device- independent model- The original Microsoft solution 
is called the Graphics Device Interface (GDI) , and it is 
the paradigm shift in video graphics technology made 
possible by this particular product component, that has 
helped promote the Graphical User Interface (GUI) to its 

10 ubiquitous market position. The invention of the GDI 
allowed the development of GUI applications that would 
run over any graphics hardware integrated according to 
the GDI's prescribed methodology (see C. Petzold, 
Programming Windows 3.1, Redmond, Washington, Microsoft 

is Press, Chapter 11, 1992. 

The principle that underlies the GDI is that there 
exists a finite set of graphical operations that will 
enable a software developer to draw just about anything 
on a bitmapped display device. It is taken into 

20 consideration that some graphics hardware is more or less 
suitable for the direct implementation of these 
operations; some operations may not be supported at all 
by the hardware. To derive a set of abstract, logical 
operations, without giving consideration to the 

25 underlying mechanism needed to support them, is referred 
to as the process of virtualization. In a GDI 
implementation, any graphics operation that may be 
supported directly by a hardware function, is accessed 
directly using a vendor-specific device driver. If a 

30 close mapping of a physical to a logical graphical 
operation exists, some software modification of the 
physical operation, to better implement the desired 
logical operation, is invoked as needed. If no hardware 
support exists for the operation, it may be emulated 

35 entirely in software, or marked as a task of which the 
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vendor-specific driver is incapable. A structured 
capability report mechanism is available to applications 
using GDI, so that they may determine if a specific 
operation is even possible. Regardless of whether a 
5 particular operation is supported by the graphics device 
per se, or can be emulated, if there is any way GDI can 
fulfill the request for service, then the graphical 
system is considered to be capable. This same 
virtualization principle behind the Graphics Device 
10 Interface can be expanded to create a logical description 
of operations necessary to fully describe multimedia 
interconnection operations. 

A VIRTUAL! ZED MULTIMEDIA CONNECTIVITY SYSTEM 

Videoconferencing is but one interesting 

is multimedia connectivity service. However, what is needed 
is a change in the way we view multimedia 
interconnection, not only in terms of the logical 
operations we wish to perform, but in a way that most 
advantageously applies those operations to specific 

20 configurations of audio-video transducers, and diverse 
sources of synchronous data connectivity. A generalized 
model for multimedia connectivity application development 
must take into consideration that the essence of these 
technologies is the structured sharing of sound and light 

25 spectral data (as opposed to binary data) . The vendor- 
specific facets of media transducers and network 
interfaces employed to implement related services must be 
rendered entirely irrelevant to the operation of software 
programs desirous of device- independent audiovisual 

30 teleservices. 

In that regard, an efficient, consistent, and 
extensible presentation of multimedia connectivity 
services to software programs is achieved through the 
appropriate run-time binding of media transducers to 
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connectivity protocol stacks. Device- independent 
multimedia connectivity services are abstracted, in 
software, to an externally consistent media and network 
interface control interface. A single binary software 
5 object is constructed to encapsulate all relevant 

hardware and software components necessary to support 
virtualized multimedia connection services. These 
services are accessed through manipulation of the 
object's members. A specific instance of the 

10 virtualized, encapsulated media control and connectivity 
components required to implement the defined services, is 
referred to as a Virtual Connection Object (VCO) . Each 
VCO contains a reusable Virtual Device Interface (VDI) 
software component that contains the VCO's Software 

15 Control Interface (SCI) and device-independent 

media/connection device control methods. The VDI derives 
implementation of its services from a Virtualization 
Layer (VL) . The Physical Device Interface (PDI) provides 
control of the physical media transducers and one or more 

20 network interface units, in a fashion consistent with 

both the techniques specified by their manufacturers, and 
in a way that enables their efficient utilization by 
methods in the VI*. Device-generated events, occurring in 
real-time, asynchronous with the system scheduler, are 

25 inserted— into an infinite event queue, to be periodically 
dispatched to the VDI, synchronous with the system 
scheduler. Physical limitations on the level of service 
provided by encapsulated media transducers /network 
interface, are expressed as the Local Capabilities. When 

30 connected, the capabilities of the remote station are 
expressed as the Remote Capabilities, and are available 
to the constructor of the VCO. The quality of the 
connection is described as the logical intersection of 
both the Local Capabilities and the Remote Capabilities, 

35 and is referred to as the Connection Capabilities. VCO 
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implementations abstract multimedia connectivity services 
to the level of the Open Systems Interconnection 
Reference Model Presentation Layer; device-dependent 
control methodologies for vendor-specific media 
5 transducers and connectivity protocol stacks have no 
representation in the Presentation Layer. Software 
programs that construct VCOs and utilize the presented 
multimedia connectivity services, are referred to as VCO 
Clients. These device- independent connectivity programs 
10 realize the benefits of interoperability across any 

multimedia connectivity sub-system that encapsulates its 
services into a Virtual Connection Object, according to 
the disclosed methodology. 

In general, in one aspect, the invention is a 
is multimedia connectivity program residing in computer 

readable memory. The connectivity program when executed 
on a computer providing to an application program 
multimedia connectivity services through a real-time 
multimedia device control subsystem including components 
20 selected from among a plurality of multimedia devices and 
a plurality of real-time multimedia protocol stacks. The 
program includes a single binary object encapsulating a 
virtual device interface and a device control interface. 
The virtual device interface includes a plurality of 
25 virtual methods that represent logical operations 

available to the application program for controlling the 
multimedia device control subsystem. The plurality of 
virtual functions are completely independent of the 
components within the device control subsystem. The 
30 device control interface mapps the plurality of virtual 
functions to physical control methods which control the 
components of the multimedia control subsystem. 

In preferred embodiments, the device control 
interface includes a plurality of media control objects 
35 which represent audiovisual and binary data streams 
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associated with the components of the plurality of 
devices and/or real-time multimedia protocol stacks. The 
virtual device interface is configured to present a 
logical representation of the multimedia connectivity 
5 services provided by the connectivity program. The 

device control interface includes a virtualization layer 
and a physical device interface layer , the virtualization 
layer being located between the virtual device interface 
and the physical device interface. The physical device 

10 interface directly interfaces to the device control 
subsystem to provide a physical implementation of 
services requested by the application through the virtual 
device interface. The virtualization layer resides 
between the virtual device interface and the physical 

is device interface layer and is configured to translate and 
map device control mechanisms employed by the underlying 
multimedia control sub-system to representations required 
by the virtual methods of the virtual device interface. 

Also, in preferred embodiments, the plurality of 

20 media control objects provides the multimedia 

connectivity control program with a pool of media device 
signal resources. Each of the plurality of media control 
objects is classified as at least one of type of the 
group consisting of an audio type, a video type r an image 

25 type-rrrand- a binary data type. Also, each of the 

plurality of media control objects represents a -signal 
from the group consisting of a signal from a remote 
station, a signal to a remote station, a signal from a 
local output device, and a signal to a local output 

30 device. The operations performed on the plurality of 

media control objects by the physical device layer under 
control of the virtual device interface implements a 
logical software switching mechanism. The virtual device 
interface implements a plurality of public member 

35 functions, the virtual functions being a subset of those 
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public member functions and the plurality of public 
member functions representing all of the public member 
functions in the single binary object that are accessible 
by the application program. 

In general, in anotehr aspect, the invention is a 
computer programmed to provide to an application program 
multimedia connectivity services through a real-time 
multimedia device control subsystem. The multimedia 
device control subsystem includescomponents selected from 
among a plurality of multimedia devices and a plurality 
of real-time multimedia protocol stacks. The programmed 
computer includes a virtual device interface and a device 
control interface, both of which are encapsulated in a 
single binary object. The virtual device interface 
includes a plurality of virtual methods that represent 
logical operations available to the application program 
for controlling the multimedia device control subsystem. 
The plurality of virtual functions are completely 
independent of the components within the device control 
subsystem. The device control interface maps the 
plurality of virtual functions to physical control 
methods which control the components of the multimedia 
control subsystem. 

In general, in yet another aspect, the invention 
is a computer implemented method of providing multimedia 
connectivity services through a real-time multimedia 
device control subsystem. The multimedia device control 
subsystem includes components selected from among a 
plurality of multimedia devices and a plurality of real- 
time multimedia protocol stacks. The method includes the 
steps of defining and supporting by computer implemented 
steps a virtual device interface; and defining and 
supporting by computer implemented steps a device control 
interface. Both the virtual device interface and the 
device control interface are encapsulated in a single 
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binary object • The virtual device interface includes a 
plurality of virtual methods that represent logical 
operations available to the application program for 
controlling the multimedia device control subsystem. The 
5 plurality of virtual functions are completely independent 
of the components within the device control subsystem. 
The device control interface maps the plurality of 
virtual functions to physical control methods which 
control the components of the multimedia control 

10 subsystem. 

Multimedia connectivity sub-systems, when 
developed for use in a VMCS, present an externally 
consistent, fully abstracted set of logical operations to 
software programs, therewith exposing the faculty to 

is create adjunct, device- independent, interoperable 

multimedia connectivity software application programs. 
The disclosed invention is a methodology to enable the 
structured sharing of spectral information between 
interconnected microcomputer stations. Though 

20 principally intended to facilitate control of live audio 
and (motion) video information, this comprehensive 
connectivity paradigm incorporates mechanisms for store- 
forward operations; binary data object transfers are also 
supported* For the purposes of practical consideration, 

25 the VMCS pursues a classic client-server model of 
application/ sub-system interaction. The sub-system 
presents a coherent software control mechanism to device- 
independent connectivity applications created explicitly 
to utilize its structured, highly-typed, set of services. 

30 Insofar as software programs benefit from 

virtualized binary data sharing technologies, the same 
benefits may be realized by those sharing spectral 
information, if the system is implemented as a 
Virtualized Multimedia Connection System (VMCS) . 



WO 98/09213 



PCT/US97/15018 



- 12 - 

Other advantages and features will become apparent 
from the following description of the preferred 
embodiment and from the claims. 



Brief Description of the Drawing 
5 Fig. 1 shows the symbol conventions used in the 

following figures; 

Fig* 2 is a block diagram showing a VCMS component 
overview; 

Fig. 3 is a block diagram showing a VCO 
10 architecture overview; 

Fig, 4 is a block diagram showing the VCO software 
architecture ; 

Fig. 5 is a block diagram showing the VCO client 
application software architecture; 
is Fig. 6 is a block diagram showing the VCO class 

derivation ; 

Fig. 6 A is a table of the VCO exception handling 
modalities; 

Fig. 6B is a table of the VCO trace output 
20 modalities; 

Fig. 6C is a table of VCO events which trigger 
notification ; 

Fig. 7 is a block diagram showing the device 
control mechanism ; 
25 Fig. 8 is a block diagram showing the VCO control 

methodologies ; 

Fig. 9 is a block diagram showing the terminal 
output control flow; 

Fig. 10 is a block diagram showing the signal 
30 triggering mechanism control flow; 

Fig. 11 is a block diagram showing the event 
queuing and dispatching control flow; 

Fig. 12 is a block diagram showing the connection 
capability control flow; 
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Fig. 13 is a block diagram shoving the capability 
and mode mapping control flow; 

Fig* 14 is a block diagram showing the call 
controller control flow; 
5 Fig. 15 is a block diagram showing the line 

disconnection control flow; 

Fig. 16 is a block diagram showing the line 
dialed, ringback, busy, and connected control flows; 

Fig. 17 is a block diagram showing the line ring 
10 control flow; 

Fig. 18 is a block diagram showing the call reset, 
mode setting, and mode restoring control flows; 

Fig. 19 is a block diagram showing the exception 
handling control flow; 

Fig. 20 is a block diagram showing the media 
control object command control flow; 

Fig. 21 is a block diagram showing the media 
device capability query control flow; 

Fig. 22 is a block diagram showing the media 
20 access control request control flow; 

Fig. 23 is a block diagram showing the device 
event processing control flow; 

Fig. 24 is a block diagram showing the object 
construction and destruction control flows; 
25 Fig. 25 is a block diagram showing the •Open" 

command control flow; 

Fig. 26 is a block diagram showing the "Close" 
command control flow; 

Fig. 27 is a block diagram showing the "Call" 
30 command control flow; 

Fig. 28 is a block diagram showing the "Multicall" 
command control flow; 

Fig. 29 is a block diagram showing the "Hang-Up" 
command control flow; and 
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Fig. 30 is a table of the multipoint control 
operations. 

Appendix: contianing source code for Virtual 
Device Interface Header File, 

5 Description of the Preferred Embodiments 

DEFINITIONS 

Provided below are definitions for terms used 
throughout this disclosure. While common technology 
parlance may assign a variety of alternative meanings to 
10 them, those definitions following refer to specific 
usages in this manuscript only, noted explicitly to 
alleviate ambiguous technology references henceforward. 



Transducer 

This term refers to a device that converts one form of 
is energy into another. Here specific reference is given to 
those that convert light and sound energy to electrical 
pulses, or inversely, electrical pulses back to light and 
sound energy. Examples include cameras, microphones, 
speakers, and video monitors. 

20 Signal 

This term refers to a digital data stream used to 
transfer raw or encoded binary information, except in the 
case of direct references to "bit-rate allocation signal 
indications • " 

25 Indication 

This term refers to a message connoting a change in state 
or modality of a system or station component; basic unit 
of notification used for the sole purpose of 
communicating the occurrence of some specific event. 



30 Notification 
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This term refers to an indication transmitted from one 
software component in the system to another software 
component in the same system. Typically used to notify 
software system components that some specific event has 
5 occurred and some response is required • 

Spectral information 

This term refers to sound and light data that are 
represented as modulations of electromagnetic or audible 
spectra; audible and visible waveform information. 

10 Binary information 

This term refers to electrical pulse data encoded as 
binary numerical values that are typically referenced in 
octets . 

Terminal 

is This term refers to as a physical or virtual teletype 
console device that displays text data output to it, and 
returns text input, such as if read from a keyboard 
device; essentially a dedicated text-processing I/O 
device or software representation thereof, with no 

20 significant processing ability. 

8 tat ion 

This term refers to an intelligent node on a network to 
which other network nodes can connect and exchange 
messages . 

25 Local station 

This term refers to the station whose resources are 
directly addressable without using an intervening network 
connection; conceptually perceived as the near-end of any 
connection. 
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Remote station 

This term refers to the station whose resources are not 
directly addressable without an intervening network 
connection; conceptually perceived as the far-end of any 
s connection. 

Sharing 

This term refers to bi-directional data transfer between 
interconnected stations on a network. 

Vendor-specific 

10 This term refers to any hardware or software system 
component that requires a non-standardized software 
control layer to accommodate the particular requisite 
interface format and control procedures described by its 
manufacturer . 

15 Multimedia 

This term refers to a class of digital computer 
technologies that store , retrieve, manipulate, and play 
back audible and visual information. These technologies 
are embodied in combined software and digital hardware 

20 sub-systems that encode spectral information presented to 
input transducers, into digital data streams that are 
then stored in a compressed format. This compressed 
digital information is later reconstituted back to 
spectral information by decompressing, decoding, and 

55 subsequent retransmission through output transducers. 

Connectivity 

This term refers to the generalized concept of 
establishing a communications link between two or more 
stations on a network, exchanging messages according to 
30 some preconceived notion of structured interaction; this 
notion of interaction referred to as a protocol. 
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Multimedia connectivity 

This term refers to the generalized concept of 
establishing an audible, and/or visual communications 
link between two or more stations on a network; These 
s technologies are embodied in combined software and 
digital hardware sub-systems that encode spectral 
information presented to input transducers, into digital 
data streams that are then transmitted across a network 
connection to a remote station in a compressed format, 

10 There it is reconstituted back to spectral information by 
decompressing, decoding, and subsequent retransmission 
through output transducers. When occurring bi- 
directionally in real-time, without delay, the connection 
between the stations is described as ■ live* , as if the 

15 input transducers of one station were connected directly 
to the output transducers of the other, and the network 
becomes conceptually irrelevant to the process* A variety 
of other media forms, such as still pictures and plain 
binary data, may also be exchanged between stations on an 

20 occasional basis, and played back as needed. 

Media Control Interface (MCI) 

This term refers to a device driver interface 
specification that allows its users to control underlying 
physical media devices using a somewhat well-defined, 
25 standardized string-token command language. 

Media Access Control (MAC) 

This term refers to that set of MCI drivers that provide 
a standardized physical device control interface layer 
between the more device-independent software layers that 
30 issue MCI string commands, and the vendor-specific device 
drivers that contain proprietary interfaces and control 
procedures to initialize, shutdown, and utilize the 
peripheral hardware components. 
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Object-Oriented Design 

This term refers to a methodology to enhance the quality 
of computer systems by describing their constituent 
components as discreet sets of related, well-defined 
5 operations whose implementations are isolated from their 
functionally described operational profiles; interactions 
between system software components are defined with equal 
precision, according to a specialized software 
development methodology. Highly-structured programming 

10 languages 1 and design tools promote creation of modular, 
reusable software components that can be recombined to 
build new components; existing components are better 
understood in terms of functionality and reliability. In 
this way, implementations of new components borrow the 

15 functionality (and demonstrated reliability) of 

preexisting software technologies to create new products, 
thereby significantly reducing development time and 
dramatically improving overall system reliability. 

OPERATING SYSTEM MODEL 

20 A more accurate technical description of the VMCS 

is that of a Virtualized Multimedia Connectivity 
Operating System. Designed for a multithreaded, protected 
memory model implementation, the VMCS server component 
runs parallel to the client applications that utilize it, 

25 the server responding to client requests with a stream of 
notifications directed to class objects located in the 
client programs. A client application invoking a VMCS 
server, spawns a concurrent operating system that 
effectively manages all hardware and software components 

30 necessary to establishing a device* independent multimedia 
connectivity service, in much the same way as any 
operating system does to support its general application 
programs. Once created, the VMCS server runs by itself, 
independent of the client, and capable of offering 



J 
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services to more than one client at the same time. Just 
as with advanced operating systems, the transactions 
between clients and servers are fully protected, and 
highly structured with regards to both syntax and 
5 sequence. The VCO Client selects an "operating system" 
that best suits the system hardware configuration, 
invokes it when needed, discards it when it is no longer 
needed, and changes it when it prefers an "operating 
system 11 with a different service profile. 

10 Consistent with the intention of its design, 

multiple VMCSs can be concurrently invoked. The VMCS, in 
accordance with the "operating system" model heretofore 
described, was intended from its inception, for 
implementation in multiprocessor or distributed systems 

15 where a separate coprocessor, parallel processor, or 
entire system could house the server component 
separately. Further, embedded implementations (for use 
with coprocessor systems) do not pose the usual 
implementation difficulties associated with sub-system 

20 designs whose client and server component were assumed to 
reside in shared memory. 

STANDARDS COMPLIANCE 

There is a well-defined modality of interaction 
between VMCS servers, and the VMCS applications that use 

25 them, the orders of whose operations are specified with 
mathematical precision. Resultantly, there is a high- 
degree of predictability in the progression of 
connectivity sessions, and corresponding measurable 
improvement in their robustness. VMCS implementations 

30 are unique in the domain of multimedia connectivity 

systems. Specifically, they make possible the creation 
of standardized software communication products, enable 
connectivity applications to run over any compliant 
connectivity sub-system, fully integrate audiovisual/data 
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connectivity services into a single control mechanism, 
reduce software development time, and expose 
extraordinary levels of derived functionality. 

This methodology is primarily a software 
5 development technique. Object-oriented software 

components are created to abstract the low-level services 
of media control and network interface components to a 
fully-virtualized multimedia connection service that 
integrates the ITU-T multimedia interconnection protocols 

10 (H.320), the Open System Interconnection (OSI) Reference 
Model, and object-oriented software design principles. 
The VMCS architecture combines these paradigms into a 
dynamically instantiable client-server multimedia 
connectivity service technology. ITU-T Recommendation 

is H.320 defines a discreet set of operations and procedures 
necessary to the sharing of spectral and binary data 
between compliant interconnected stations. It enables 
reliable, structured data transfer and device mode 
synchronization to. stations connected to the Integrated 

20 Services Digital Network (ISDN) . A VMCS implementation 

employs the ubiquitous H.320 recommendation as a rigorous 
definition of its most basic set of multimedia 
connectivity operations. For stations that access the 
ISDN, this application of H.320 is natural and obvious, 

25 but the VMCS goes on to take further advantage of the 
apposite H.320 structure. The VMCS architecture insists 
upon the promotion of the H.320 protocol set to that of a 
universal framework to which even non-compliant protocols 
can be promoted. 



30 ARCHITECTURE 

OSI REFERENCE MODEL 

Connectivity system developers can abstract the 
presentation of non-compliant services to a 
representation more efficiently managed by applications 
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(that are typically unconcerned with the specific 
requirements of the control mechanisms) . The Open System 
Interconnection (OSI) Reference Model defines a layering 
model offered internationally as a generalized system 
5 architecture to affect the designs of connectivity 
software systems, particularly with respect to host 
stations desirous of reliable interconnection . For any 
host operating system (OS) , a Virtualized Multimedia 
Connection System (VMCS) provides an exact definition of 

10 the OSI Presentation Layer that serves as the interface 
between a connectivity application (client) , and the 
connectivity sub-system (server) . The majority of 
software components, common to all VMCS implementations, 
are reusable versions of the services specified to reside 

is in the OSI Session Layer; they provide device-independent 
implementations of the protocols represented by the H.320 
rubric. Media control and network interface 
manufacturers are usually best qualified to supply low- 
level device/protocol support drivers that comprise the 

20 OSI Transport, Network, and Data Link Layers. The VMCS is 
most efficiently implemented when it leaves this task to. 
them, and instead builds on their work. For specific 
media control and connectivity tasks, it is often 
indeterminate as to whether a device, or software 

25 component, will comprise the best utensil. Since the OSI 
Reference Model is functionally specified, a system 
developer has the flexibility to derive a VMCS sub- 
component, or entire OSI Layer, in a way that best 
supports its design specification, regardless of whether 

30 it is build with existing or newly created sub- 
components . 



OBJECT-ORIENTATION 

Both VCO Client and server software components are 
developed with an object-oriented programming language, 
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according to a precisely-defined class inheritance and 
derivation hierarchy, A binary software object is created 
to encapsulate disparate software components into one 
functional entity , whose services are available only 
5 through structured access of its control elements (member 
functions and member data) . The strategy of all VMCS 
designs, derived by the application of this methodology, 
is to encapsulate media control services, connectivity 
services, and protocol support components, together, in a 

10 way that best integrates their properties into an 

instance of a standardized multimedia connection service 
to be used by device- independent client applications. 
Specific protocol support procedures, and media control 
components, are shared by all VMCS implementations; 

15 usually they are worth preserving, fine-tuning, and 
carrying forward to new implementations. VMCS 
implementations created to support new hardware 
configurations are most accommodating to this 
circumstance, to the extent that they are typically minor 

20 modifications of a reference VMCS implementation. New 
VMCS implementations may be designed in one of three 
modalities. First, a VMCS can be developed to exploit the 
services of an existing multimedia connectivity product 
(hardware and software sub-system layers) manufactured by 

25 a third party. Such a project would restructure 

proprietary controls of the native interface, coercing 
(virtualizing) them to the structured consistency defined 
by the VMCS paradigm. A second modality is to create a 
presentation of the defined VMCS services for a new 

30 device set, creating all device control components, VMCS 
components, and perhaps the devices themselves. Lastly, 
designs can, at run-time, invoke a particular 
presentation of services, derived from the ad hoc 
association of media control devices with selected 
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connection services, in a way most suitable to producing 
a desired multimedia connectivity service profile* 



CLIENT/SERVER MODEL 

Notwithstanding the flexibility afforded by 
5 software implementations, it is useful to describe the 
works of the VMCS in terms of discreet, mechanical 
components. There is no requirement for any component to 
be implemented entirely in hardware, or entirely in 
software, per se, so the distinction will not be brought 

10 to bear on this discussion. There are two major 

components in any VMCS: the multimedia connection sub- 
system (server) , and an application program that invokes 
its services (client) . Any VCO client application can 
invoke the services of any server, without hesitation,. 

15 with a guarantee of compatible access. More nebulous is 
the parity between the quality of services requested by 
the client, and those provisioned by physical devices 
encapsulated in the server. Strictly speaking, the server 
is the binary software object that encapsulates the media 

20 control and connectivity sub-system. It is referred to as 
a Virtual Connection Object (VCO) , and the client 
application that invokes usage of its services, is 
referred to as a Virtual Connection Object Client 
Application (VCO Client) . In this section, the scope of 

25 the discussion will be limited to a functional 
description of these entities. 



SERVER COMPONENTS 

Virtual Connection Objects are binary software 
objects that encapsulate the media control and 
30 connectivity components requisite to the implementation 
of a discreet subset of multimedia connectivity services. 
They are invoked and adjusted by manipulation of their 
members. When constructed, a VCO dynamically builds the 
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particular operational context of hardware and software 
components needed to best implement virtualized 
multimedia connection services* Destruction of the object 
deletes this operational context by shutting down all 
5 components, turning off devices, and releasing any 
allocated resources. For the host OS, every 
implementation of such an object presents members that 
are identical in syntax , -structure , and usage. In fact, 
every VCO is functionally analogous in its control 

10 mechanism, but unique in both its name, and the degree to 
which it is able to realize the full set of VMCS services 
defined to be represented in every instance thereof; that 
is each VCO has a unique set of capabilities. Inherent to 
every VCO, is the ability to provide metrics describing 

15 the potential quality of services locally available, and 
the actual quality of services available while connected 
to a particular remote station. The service profile of 
the unconnected local station is available prior to 
device initialization (but after VCO construction) , for 

20 casual examination by interested VCO Clients; this 

profile is referred to as the Local Capabilities. The 
service profile of a remote station is available while it 
is connected to the local station, and this profile is 
referred to as the Remote Capabilities. Also available 

25 when connected, is the service profile of the connection 
itself, referred to as the Connection Capabilities. This 
is the preeminently useful metric, and quantifies the 
potential quality of interactions between the local and 
remote stations; precisely, it is the logical 

30 intersection of the local and remote capabilities. 

A real-time reporting mechanism alerts system 
software objects of changes in the specific states, 
modalities, and conditions critical to the operation of 
the encapsulated multimedia connectivity sub-system. The 

35 basic unit of information, or indication, is referred to 
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as an Event, and each VCO contains a specialized delivery 
system that can notify software components in the host 
system when one such event has occurred; a Notifier 
Object is the mechanism for this delivery. Notifier 
5 Objects are triggered by the occurrence of any event type 
to which they are programmed to respond, and they are 
used both internally by the VCO, and externally by its 
clients. Finally, it should be pointed out that a VCO is 
implemented to present the services of one particular 

10 configuration of media control /network interface setup 
that comprises the multimedia connectivity sub-system, 
and it is likely each significantly different hardware 
and/or software configuration will require a somewhat 
different VCO implementation; a VCO is a device-dependent 

15 entity. 

CLIENT COMPONENTS 

Applications programs described in the VMCS are 
referred to as Virtual Connection Object Clients, are 
device- independent, software application programs that 

20 invoke VCOs, and manipulate their members to control live 
information-sharing sessions with remote stations; to 
that end, they create use-specific logical combinations 
of currently available audiovisual /data resources to 
support a defined set of multimedia connectivity tasks 

25 that is the embodiment of that particular connectivity 
application. They are developed in an apriori fashion, 
according to a concise, multimedia connectivity software 
control interface specification, the integral 
implementation of which each VCO must contain. Clients 

30 dynamically invoke at least one appropriate VCO, selected 
(from a library) according to some notion of suitability, 
and then construct it only when a connectivity session is 
actually to be initiated. VCO Clients create instances of 
Notifier Objects, and utilize them as a mechanism to 
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respond (more -or- less instantaneously) to occurrence of 
divers events to which they have been rendered sensitive. 
A client software object that contains member functions 
to receive, and respond appropriately to, these signaled 
5 events, is referred to as a Notification Receiver Object. 
Clients may monitor and/or intercept connectivity and 
device control related occurrences in the encapsulated 
sub-system, by creating- instances of VCO Notifier Objects 
with specific response profiles. These Notifier Object 

10 response profiles may be reconfigured ad hoc; they define 
the set of specific events that will trigger 
notifications (when a specified event occurs) to one 
identified NRO. There can be only one NRO associated with 
a particular instance of a Notifier Object. In a given 

15 host OS, any VCO Client can function using any VCO; a VCO 
Client is a device-independent entity. 

METHOD 

Here follows description of a method to implement 
a preferred embodiment of a Virtualized Multimedia 

20 Connection System (VMCS) . The scope for the disclosure 
will be restricted to an elucidation of those elements 
required to derive a design specification for a fully 
device-independent multimedia connection system; a system 
to be built from third-party media control devices, 

25 device drivers, and a connectivity protocol stack running 
over a network interface unit. All VMCS software 
components are created with an object-oriented 
programming language (see M.A. Ellis and B. Stroustrup, 
The Annotated C++ Reference Manual, Reading, 

30 Massachusetts, Addison-Wesley , 1990). Attendant source 
code provides a precise definition of the host/client 
software interface, and an example of a simple, portable 
device- independent connectivity application. 
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The design of this system will be considered 
initially from the perspective of an overview, and 
subsequently as a functional examination of its component 
interworkings • Next comes a detailed examination of 
5 critical software and hardware constructs needed to 

physically implement a VMCS design. The topic concludes 
with a discussion related to the deployment of a working 
system in an actual host computer system. For this 
section in particular, the examinations of system details 

10 remain more generalized in the start, and are more fully 
later resolved, the strategic intention to permit a 
system engineer to pursue a top-down design approach for 
his particular VMCS adaptation. Compliant designs will 
produce products supporting exact binary compatibility 

is between every VMCS created for the same target operating 
system, and exact functional compatibility between every 
VMCS, regardless of the target operating system. 

DESIGN 

VISUAL TELEPHONE SYSTEM MODEL 

20 The creation of a visual telephone system is the 

most likely application for a VMCS implementation. Such 
a system illustrates all of the basic components that 
comprise the set of media control, network interface, and 
software control features common to most such solutions 

25 now available. The ITU-T describes a generalized model 
for this type of system in a document referred to as 
Recommendation H.320. This discussion, as related to a 
VMCS implementation, is best served by a similar 
treatment of the subject, as it relates to the task of 

30 deriving a virtualized model of multimedia connectivity; 
the VMCS software abstraction represents the functional 
aspects of the generalized visual telephone, with some 
notable extensions to its base level utility. It must 
also be pointed out that a VMCS implementation in no way 
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relies upon the ITU-T recommendations below the level of 
the signal and indication protocols specified by H.320 — 
any network or connectivity sub-system could conceivably 
be adapted as the underlying network transport layer* 

5 ELEMENTS OF A VISUAL TELEPHONE SYSTEM 

The prototypical VMCS system relies on divers 
hardware and software components to transfer audio, 
mot ion- video , still pictures (images), and binary data 
objects between stations connected to the same network. 

io Devices and control systems described below should be 
considered in terms of being functional entities; the 
potential to support device characteristics with a 
software emulation module is an implementation 
alternative that does not alter the basic strategy of 

15 VMCS design. In fact, input from, or output to a 

transducer device can be simulated by a data stream read 
from, or written to backing store. 

I/O Equipment 

These devices are referred to as transducers in 
20 that it is their primary task to convert energy forms 
from spectral to pulsed electrical, or vise-versa. In 
practical terms, these devices are the only parts of the 
system with which the user interacts directly. 

• Audio devices include stationary microphones 
25 and related sound detection equipment to 

input the voice of the user. For output, 
loudspeakers and headphones are output 
transducers in a VMCS. 

• Video devices include a camera to input 

30 motion-video images of the user. For output, 

video monitors display motion-video, as do 
dedicated analog (NTSC/PAL) video displays 
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• Image devices include a camera to input 
images, as well as scanners to capture high- 
resolution images. For output, video monitors 
display images, and in addition, printers 

5 that can render images are considered output 

transducers . 

• Data devices do not convert energy forms, but 
are essentially "locations" in the system 
through which data flows, or in which it is 

10 stored. Data devices include any backing 

store (disk) entities, or data ports, such as 
a communications port. Dedicated data 
streams, or "socket" interfaces would also 
qualify as valid VMCS inputs /outputs for 

15 binary data. 



CODEC 

These devices compress data from input transducer 
devices prior to transmission or storage, or inversely 
decompress data following transmission from a remote 

20 station or retrieval from storage. The process of 

compression is referred to as encoding, as spectral data 
is encoded according to an algorithm; decompression is 
correspondingly referred to decoding. Visual telephones 
transmit and receive audio and video data in a compressed 

25 format so as to enhance the efficiency of the system in 
its endeavors to exchange large volumes of audio and 
video data across connections that only support a very 
limited bandwidth. Storage of images to disk proceeds in 
the same way to reduce the amount of storage space 

30 required. 

• Audio do/ compression devices are typically 
incorporated together with H.221 
encoding/decoding hardware used for video 
processing; audio compression and 
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decompression are often accomplished in 
software. 

• Video de/ compression for live motion-video 
conferencing is best accomplished with 

5 hardware specifically designed for H.221 

encoding/decoding; video compression in 
software (for high quality video) is 
typically unsatisfactory. 

• Image da/ compress ion for images is typically 
10 done in software according to a specialized 

algorithm (such as JPEG) or transmitted as a 
simple bitmap. 

• Data de/compression is typically not 
required, save only when the data object 

15 itself has been compressed prior to 

transmission, as part of a separate 
operation. 

Telematic Equipment 

These are facilities (devices or software 
20 components) that act a visual aids to enhance 

conferencing. Application sharing features, common 
whiteboards, and image transceivers are included in this 
category, as are scanners and facsimile devices attached 
to communications ports on the visual telephone station. 



25 Multiplexors/Demultiplexers 

Signal multiplexing and demultiplexing operations 
are typically combined into a single hardware device that 
combines the audio, video, and related data streams to 
the single H.221 frame structure (multimedia signal) used 
30 in line transmission, and restores them to their 
constituent data streams upon receipt from a remote 
station or storage entity. 
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Network interface 

This component is typically a hardware device that 
provides the physical connection between the host station 
and the network, though software simulations may provide 
5 an emulated version of the same. 

Network 

Any transport medium supporting actual or emulated 
line transmission of the H.221 signal and indication 
portion of this protocol, and capable of synchronous (and 
10 simultaneous) audio, video, and binary data transport. 
Examples of recommended network types include the 
following: 

• ISDN (Basic and Primary Rate Interfaces) 

• B-ISDN (Using ATM) 

15 • LAN (FDDI and high-bandwidth proprietary 

technologies) 

• Mobile/Radio (and other wireless) 

• Analog (PSTN) 

Multipoint Control Unit 

20 This is a specialized device whose functionality 

is described by ITU-T Recommendations H.24 3 and H.231. 
The functionality of this device must be available for an 
implementation of a VMCS that is fully capable of the 
entire set of VMCS-defined multipoint control operations. 

25 System Control 

The VMCS is an implementation of this (system 
control) visual telephone system component, but conceived 
as a more generalized model suitable for utilization in a 
broad range of concurrent audiovisual/data sharing 
30 applications. The VCO component of the VMCS allows a 
device- independent connectivity client application to 
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utilize any audiovisual device control system services 
related to those of the defined visual telephone system. 

VISUAL CALL PROGRESSION 

A VMCS session takes the form of a visual 
5 telephone call* This interconnection procedure is 

precisely defined, and permits interoperability between 
dissimilar stations sporting diverse equipment 
complements, while retaining compliance to ITU-T 
Recommendation H.320. It would not be possible to utilize 

ao the plethora of potential operating modalities of VMCS 
systems without a thorough categorization of the set of 
all those modalities known to be supported by the local 
station's equipment configuration. Further, each station 
participating in a connectivity session (call) must come 

15 to an understanding of the modalities supported by its 
counterpart at the other end of the connection. What 
ensues at the time of the call is a planned negotiation 
that pits the performance expectations of the local 
station (as to the set of operating modalities it would 

20 ideally prefer to assume during the session) , against the 
cataloged limitations of its remote station peer; a 
common set of operating modalities they both must co- 
operatively determine and ultimately share for effective 
audiovisual communication. 

25 Establishment of Visual Telephone Call According to H.320 

Shown below are the basic steps common to 
establishing a "normal" visual telephone call. This 
sequence is idealized in that it does not suffer 
interruption or complication as frequently occurs in 
30 actual use. Notwithstanding the inevitable anomalies 

encountered during live operation, the following sequence 
provides a model for call progress; one that must be 
implemented by every VMCS connectivity sub-system, and 
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one derived directly from the ITU-T visual telephone call 
procedure as follows: 

1) Call setup, out-band signaling (H.200) 

A request is made to the network for a 
5 connection to a remote station. Indication is 

received at both ends to indicate when this has 
occurred, and a bi-directional data channel from 
end to end is opened for use. This data channel 
carries multiplexed multimedia data between the 

io stations. A device- independent call control 

mechanism is integral to all VMCS server 
components (Virtual Connection Objects) and 
operates directly to manage the call states and 
related operations required to create the 

is connection and data channel. 

2) Mode initialization on initial channel (H.242) 

An exchange of device capabilities takes 
place once the connection is created and frame 
alignment for the data channel is achieved. It is 

20 at this time that the VCO call controller 

initiates sending its own capabilities to the 
remote station. It also receives and stores 

capabilities sent from the remote station. A 

common base-level audio mode is selected. by the 

25 stations according to availability indicated by 

the exchanged capability sets. In the VMCS, any 
connection established must engage in the exchange 
(or emulate the exchange) of a capability set. A 
minimal bi-directional data channel must also be 

30 established in this phase. A capability exchange 

between stations can be initiated from either end, 
and may reoccur at any time (while connected) to 
assert a new ability recently assumed by a 
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station; a device may be turned on or off during 
the session, thus changes the stations capability 
profile. 

3) Call setup of additional channels (if used) 

5 Though not always used, the VCO supports 

connections of two separate lines. While network 
configurations may use six or more separate lines 
for a call, they are typically bonded together as 
one call and thus appear as a single line call to 
10 system call control. Call setup for additional 

lines proceeds in an identical fashion to that for 
the initial channel. 

4) Initialization on additional channels (if 
used) 

is Though only used if additional channels have 

been established, capability exchange and mode 
selection proceeds as for the initial channel. 

5) Establish common parameters (H.2 42) 

Both stations have available a list of the 

20 other's capabilities. Each VMCS has associated 

with it, a specific conference profile parameter 
that is used to specify the operators preferred 
operating properties. Examples include a bias 
towards better video quality, or better audio 

25 quality. Coupled with this profile is a set of 

operating modalities that can be supported by both 

* ends of the connection, and the preference of the 

remote operator. According to the physical 
limitations of the remote station's device 

30 capabilities, and in hopeful compliance with the 

preferences of the operator, a device mode 
negotiation mechanism seeks to algorithmically 
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deduce the most suitable set of device modes for 
the call by interacting with the remote station to 
realize them. 

6) Visual telephone communication (H.261) 

This phase refers to the fully established 
session itself, whereby audio, video, and binary 
data exchange can" take place over existing data 
channels. The H.320 Recommendation states that 
visual and audio communications must be active in 
this phase, though the VMCS allows for idle 
connections during which time no data exchange 
takes place; that is audio and video may be 
disabled, while the connection is still 
technically active. 

7) Termination 

When one user hangs up, an indication is sent 
to the other end to signal termination of the 
call, in the form of disconnection signals for all 
lines. Such action by one end, initiates the call 
termination process; the initiating station shuts 
down all of its data transmission to the remote 
station. Out-band signaling is typically used for 
the purpose of disconnection. 

8) Call release 

Once termination has been initiated (when the 
other end receives this message) the station sets 
data transmission to idle for each disconnected 
channel. When all lines in the call have received 
disconnection events and been set to idle, the 
call is considered to be disconnected. Individual 
lines can be added or removed as needed, without 
disconnecting the entire call. 
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VMCS SYSTEM OVERVIEW 

FIG. 2 depicts an overview of the major components 
of a Virtualized Multimedia connection System. There are 
four significant entities shown: The Virtual Connection 
5 Object (VCO) , the Virtual Connection Object Client 

Application (VCO Client) , I/O devices, and the network. 
The VCO and the VCO Client are the subject of this 
disclosure. The I/O devices are connected with a direct 
physical link to adapter boards in the host system that 
10 permit the physical control of the I/O devices via device 
driver. Essentially, the only link the VCO has to these 
devices is through a vendor-specific Media Access Control 
software layer (or some other device driver), and the VCO 
link to the network interface unit is through a 
is standardized, or vendor-specific network protocol stack. 
The network protocol stack shown in the drawing is likely 
some OSI Transport Layer abstraction of a connection 
service. 

Summary of VMCS system overview 

20 From a conceptual standpoint, the VCO combines the 

services of the data transfer (network) service with 
associated media transducer devices, so as to reliably 
offer system command and control of a derived multimedia 
connectivity service to an application program. There are 

25 two primary components of any VMCS; they are as follows: 

• The Virtual Connection- Object (VCO) 
encapsulates all of the server components 
that are required to abstract a virtualized 
representation of the media control and 

30 connectivity sub-systems, offering it to 

device-independent connectivity clients. 

• The Client Application (VCO Client) 
constructs and utilizes the virtualized 
multimedia connection services hidden away 
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inside the VCO by manipulating its member 
functions and member data. There are a number 
of specific objectives motivating this 
object-oriented system design, the substance 
of which receives commentary below: 

System Design Objectives 

Design-level Support for VMCS Services 

The objective of the VMCS design is to provide 
design-level support for a full visualization of any 
multimedia connection system, so that device -independent 
representations of a logical control mechanism could be 
ported to a wide variety of supporting media control 
devices and network interface. Client applications 
designed to utilize VMCS technology are interoperable 
with every VCO implementation (running under the same 
operating system) and thus more efficiently distributed, 
maintained, supported, and redeployed with new device 
complements. Most important is the ability to bind any 
network interfaces to any media control interface by the 
addition of specialized hardware and software layers that 
combine the functions of these components without 
affecting its mechanism of control. New and different 
underlying technologies are well utilized, however the 
extensible VMCS virtualization paradigm leaves their 
often peculiar operating procedures fully obscured from 
the view of application programs. 

Progressive Isolation of Sub-system from Applications 

The VCO component of the VMCS incorporates a 
number of design methodologies whose purpose is to 
dissociate the control of services, from their physical 
implementations. The Open System Interconnection (OSI) 
Reference Model (see B. Hebrawi, OSI Upper Layer 
Standards and Practices, New York, NY, McGraw-Hill, 
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pp. 11-15, 1993) and object-oriented programming languages 
are primary building blocks in any VMCS. 

• OSI Layering underpins the structure of the 
VMCS in that the VCO is a logical 
encapsulation of all of the OSI layers below 
the presentation layer. The VCO members 
themselves comprise the OSI Presentation 
Layer implementation, whereas device- 
independent routines in the upper VCO layers 
form a discreet and reusable OSI session 
layer - 

• Class Structure of the VCO is rigidly defined 
so as to preserve the largest number of 
functional source components from 
modification, and to maintain the design 
integrity of the VMCS . Class components 
allow for a definitive specification of 
distinct, isolated functional units that will 
not affect their interactions with related 
components when their internal 
implementations have been modified to 
accommodate the operational characteristics 
of vendor-specific components. 

• Discreet Member Profile preserves the 
modality of the interface that makes each and 
every VCO implementation appear the same to 
clients, and consequently it is most 
essential to maintain its form to enable 
interoperability for all clients. VCO 
Clients assume that the specific member 
profile of every VCO is identical, thus each 
can be invoked and utilized without concern 
for incompatibilities between them. 

• Token-based Job Description Language is a 
text-token representation of the VCO member 
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functions and their highly structured 
enumerated arguments. If the structure of the 
VCO interface is consistent (over time) and 
reducible to simple string commands, then it 
is possible to reduce the control of any VCO 
to a series of text messages in a character 
stream. From this approach is derived the 
capacity to remotely control a VCO. User 
applications are almost entirely isolated 
from the server component in that each server 
(VCO) functions as a command interpreter. 

Client Components 

The VCO client in FIG. 2 is a device- independent 
layer that is dynamically portable at run-time to other 
VCO-encapsulated multimedia connectivity sub-systems. All 
VCO Clients are fully interoperable with all server (VCO) 
layer components that offer a consistent presentation 
(OSI Presentation Layer) constructed according to an 
interface specified in this document. Notification calls 
from the VCO to the client can occur spontaneously, 
asynchronous with other system events, and concurrent 
with notifications emanating from other VCOs invoked by 
the same client, thus most client modules should be 
designed to support re-entrancy and mutual-exclusive 
access to resources. A multithreaded implementation 
strategy is most efficient to manage the various, often 
concurrent tasks related to simultaneously maintaining 
the visual information presented to the user, and 
supporting the command, control, and real-time monitoring 
of the multimedia connectivity sub-system. Regardless of 
the frequency of device interrupt requests or the rate of 
message passing between interconnected stations, the flow 
of notifications from the VCO to the client is conducted 
according to a dynamically configurable interval that a 
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10 



15 



client can optimize according to its particular needs. In 
reality, the client runs at operating system speeds 
determined by the system scheduler, while low-level 
device control components in the VCO run at device speeds 
determined by the network and the devices themselves. 
Resultant ly, VMCS systems share the following 
characteristics : 

• Applications can vary the periodic rate at 
which they are actually notified of device 
events occurring sporadically, in real-time 

• Applications never miss events, and are never 
unable to respond to them due to their 
occurring in time slices not allocated to the 
application. The VCO notifies its client 
application that a particular event has 
occurred, by scheduling the application to 
run, in response to that event, on a special 
thread created by the VCO event dispatcher. 

• Application processing of device events 
catches up to the rate at which the device 
produces them, by continuing to send 
notification of events to the application 
during I/O latency periods when the device is 
less active. 

25 # critical section handling, as related to 

device interrupts and the management of 
device driver queues, is fully managed by the 
VCO, thus the application may process 
notification events at a high-level; it is, 

30 by design, nearly impossible for an 

application to corrupt the timing and real- 
time operation of the low-level device 
control sub-system. The application sees 
these sub- systems as a stream of interesting 



20 
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events, none of which requires attention for 
proper VCO operation. 

Application Shell 

The application shell is preferably an event- 
5 driven graphical user interface (GUI) program written in 
an object-oriented programming language. There are no 
special considerations for VMCS integration. Retrofitting 
of existing GUI programs, to work as VCO Clients, is 
easily accomplished. In fact, any application shell that 

10 constructs a VCO is defined as a VCO client, and only a 
modicum of member functions need be called to establish a 
fully operational connectivity session to a remote 
station. A daemon that constructs a VCO, and fields 
string commands from a hardware or software data port, 

is can serve as a non-interactive VCO client. 

Notification Receiver Objects (NRO) 

These software objects are created to provide a 
structured mechanism for responding to VCO events. Any 
application class object can contain a specific member 
20 function and adjunct function mapping component to direct 
the VCO to send a notification message to that object 
upon the occurrence of any set of specified events. 

VCO Components 

The VCO utilizes a three-layer software design 
25 that converts the native modalities and properties of 
some set of physical devices to those that can be 
accurately described using the parameters specified by 
the VCO. Underlying the software components are device 
control components used to physically operate the media 
30 control and connectivity sub-systems. These low-level 
components, and the devices that they control, are 
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typically provided by a third party specializing in their 
respective technologies . 

Virtual Device Interface (VDI) 

Provides a logically-defined, or virtualized 
5 interface to services that would be offered by an 
idealized, functionally advanced combination visual 
telephone/ imaging system. The VDI is a reusable shell 
that is common to all VCO implementations (in a given 
OS) • 

10 visualization Layer (VL) 

Translates logical operations defined in the VDI, 
to physical implementations (of those most similar) 
provided by the PDI. The VL is set of mostly reusable 
routines that are, as needed, partially reimplemented to 
15 work with a particular device set in the PDI. In many 
cases, VL components may include direct accesses to 
vendor-specific connectivity protocol stacks and media 
control components . 

Physical Device Interface (PDI) 

20 Provides a physical, or driver-level interface to 

actual physical devices assigned to the control of the 
VCO implementation. The PDI inherits virtualization 
functions from the VL to provide a rigidly compliant 
implementation of a device control interface used by the 

25 VDI directly to provide support for its logically defined 
tasks. PDI implementations include direct accesses to 
vendor-specific connectivity protocol stacks and media 
con t r o 1 components • 

Encapsulated Devices 

30 The encapsulated devices in a VMCS typically 

include a network interface unit and a host of related 
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media control devices. The connectivity protocol stack 
refers to the software layers necessary to provide 
services defined for the OSI Transport Layer; that is, it 
must ensure the reliable transfer of messages between end 
5 users. Media Access Control must contain drivers enabling 
physical operation of all devices relegated to VCO 
control, as previously specified in the section entitled 
DEFINITIONS. The types of devices likely to be 
incorporated into the VCO design, will be some variation 
10 upon those described to manage audio, video, images, and 
binary data, as specified in the section entitled I/O 
Equipment . 

Component Interactions 

There are well-defined modalities of interactions 

is between VHCS components. The VDI makes direct use of PDI 
members to invoke the services of physical devices in its 
mission to fulfill VCO Client requests for services. The 
PDI, in turn, calls functions in the connectivity 
protocol stack and in the Media Access Control layer. The 

20 PDI calls member functions in the VL to provide the 

mapping, translation, and formatting necessary to coerce 
the low-level services to resemble those logically 
specified by the VDI. As they occur in real-time, events 
generated by the connectivity protocol stack and Media 

25 Access Control components are added to a general VCO 
event queue. A dispatcher in the VCO removes events 
periodically, synchronous with the operating system 
scheduler. An event processor in the VL responds to 
events as they are dispatched to it, invoking other VCO 

30 components as needed. Some of these events require that 
the client application be notified of their occurrence, 
if the client has so arranged. 
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VCO ARCHITECTURAL OVERVIEW 

FIG. 3 depicts a functional block diagram of a 
VCO, with components partitioned according to the VCO 
layer where they reside. This section provides a high- 
5 level view of the VCO sub- components' functional 

organization. Subsequent sections pursue a more rigorous 
examination of the constructs themselves, here only 
topically considered. It is more important to note that 
the VDI, VL, and PDI sections labeled "Device /Protocol 

10 Controllers" are to be considered as layer-specific 

overlays of the same groups of components. The groups in 
the VDI section "Device /Protocol Controllers" illustrate 
the logical definitions for each of ten distinct 
functional categories; corresponding groups in the VL and 

15 PDI describe the identically functional categories, but 
at a different level of software abstraction. All 
components in the VDI section are fully reusable, device- 
independent software components. Those components in the 
PDI are vendor-specific and implementation-specific while 

20 those in the VL are mostly device- independent, but may 
require some implementation-specific coding to support 
wide variations in the underlying device control 
software. 

Software components in the VCO are physically 
25 divided into very specific object entities, each of which 
much interact with those adjunct and adjacent. A set of 
related functions and data structures combine 
synergistically, are referred to as a controller. Such 
entities are the basic functional units of the VCO in 
30 that they form discreet functional "parts" that control 
and/or manage a well-defined set of tasks. 



Summary of VCO Architectural Overview 

The VCO is a single binary software object that 
encapsulates all of the hardware and software components 
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necessary to implement a fully Virtualized Multimedia 
Connection System. Virtualization of the services 
provided by disparate connectivity and media control 
systems is rendered according to three-layer progressive 
5 abstraction strategy that relies upon object-oriented 
software technology for both its design and 
imp 1 emen t a t i on • 

• A device- independent, reusable software 
layer call the Virtual Device Interface (VDI) 

10 is created to provide a detailed logical 

description of a virtualized multimedia 
connection service. It has as set of public 
member functions that define its interface to 
applications and other invoking software 

15 modules. Included in this layer are a series 

of software controllers that are specifically 
here located (in this logical layer) to 
embody the larger part of the system' s 
software implementations in a layer that 

20 would be directly propagated to new system 

implementations, wherefore to facilitate the 
creation of a highly reliable, reusable, 
portable modules. 

• A mostly reusable, and predominantly device- 
25 independent intermediary software layer 

called the Virtualization Layer (VL} is 
created to assist in the process of 
translating and mapping the functions of 
various device control mechanisms employed by 
30 the underlying connectivity and media control 

sub-systems, to the logically defined virtual 
representation required by the VDI. 

• A device-dependent layer called the Physical 
Device Interface (PDI) interfaces directly to 

35 the device control sub-system to provide a 
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physical implementation to the service 
requested by the VDI. The PDI makes use of 
virtualization functions in the VL to coerce 
the particular message and data output 
5 formats of vendor-specific device control 

components, to a structured format integral 
to the VCO design. 
• Audiovisual and binary data streams in the 
PDI sub-system are represented as Media 

10 Control Objects (MCO) . A list of these 

objects is maintained by the PDI so as to 
present the VCO with a pool of available 
media device and signal resources. According 
to the media type, and its direction of flow 

as in the system, these MCOs are classified 

accordingly as either an audio, video, image, 
or binary data type. They are further 
characterized as a signal from the remote 
station, to the remote station, to a local 

20 output device, or from a local output device. 

Operations performed on these objects modify 
their properties and modalities of 
interaction, so as to provide the VCO with a 
logical software switching mechanism for its 

25 encapsulated media control device inputs and 

outputs. 

Virtual Device interface 

The device- independent portion of the VCO, is a 
fully reusable entity that is created once, and then 
30 propagated to all VCO implementations. It contains the 
definition of all the VCO public member functions 
accessed by clients. These members are collectively 
referred to as the Software Control Interface (SCI) , 
which itself includes a number of other VCO control 
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mechanisms whose functionality extends well beyond simple 
calls to members. The VCO event notification mechanism 
and terminal stream I/O manager are integral to the VDI, 
as are ten controllers related to implementation of the 
5 services requested through calls to SCI members. 

Software Control Interface Functional Groups 

These groups of "control members* 1 contain the 
member functions used by clients to invoke VCO services. 
Each relates to a set of public VCO member functions used 
10 to access a specific class of well-defined operations. 

• Event Notification Control Members enable the 
creation, deletion, and configuration of 
"Notifier Objects" (NO) that may be 
programmed to trigger on the occurrence of 

15 any one of a defined set of VCO events. When 

a Notifier Object triggers, it make a 
function call to a special member function of 
a specified object, and thereupon conveys 
information concerning the event that 

20 occurred. 

• Configuration/System Setup Control Members 
enable VCO configuration information to be 
saved to, or retrieved from backing store. 

• Terminal Services Control Members enable 
25 writes of text messages to VCO terminal 

output port, and command input through the 
VCO terminal input port. They also allow the 
VCO terminal output port to be attached to 
various output devices. 
30 • Network Session Control Members enable 

establishment of a network session with a 
remote station. They include members to 
invoke initialization and shutdown of the 
physical device control sub-system, as well 
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as to place point-to-point and multipoint 
calls. 

• Audiovisual /Data Signal Switching Members 

enable signals to/ from the remote station, 
5 and to/ from transducers to be manipulated, 

combined, and interconnected in various 
combinations . 

• Binary Data Object Exchange Control Members 
enable buffers, files, and other binary data 

io entities to be transferred between the local 

and remote stations. 

• System Information Store/Retrieve Control 
Members enable access to VCO parameter blocks 
containing information about their 

is encapsulated devices, current call states, 

protocol states, configuration, and 
control /monitoring context. 

• Protocol Management Control Members enable 
direct manipulation of the H.320 protocol 

20 whose implementation is integral to the VCO. 

Allows advanced operators to perform mid- 
level operations to configure the VCO, and 
any connected remote station, according to 
the procedures of H.320. 



25 Notification Controller 

This notification mechanism is used both 
internally by the VCO, and by client applications that 
wish to monitor, or respond to specific system events. A 
Notifier Object is created, and programmed to respond to 

30 any subset of the cataloged VCO events. If the event 

occurs, a special notification member in a target object 
is called and passed information regarding the occurrence 
of the event. The Notification Controller refers to all 
of the member functions and member data necessary to 
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implement the notification mechanism in each VCO. It 
contains three distinct parts that operate both 
independently and together, depending on the notification 
task at hand. 

5 • Notification Triggering Mechanism is 

responsible for determining exactly when a 
Notifier Object should trigger, by examining 
its list of triggering events when one such 
event occurs. If the Notifier Object is set 

10 to trigger on the event, it is activated to 

initiate its trigger sequence, thereupon 
informing a specified software object that 
the event has occurred; it passes parameters 
during a call to a notification member 

is function. 

• Notifier Object List Manager is responsible 
for creating, deleting, modifying, and 
querying a database containing all Notifier 
Objects for the VCO. 

20 • Linked Notifier Object List is a doubly 

linked list of all Notifier Objects for a 
VCO, and it is maintained by the Notifier 
Object List Manager. 

Terminal Stream Controller 

25 This terminal stream mechanism is used both 

internally by the VCO, and by client applications that 
wish to direct streams of text messages to a configurable 
set of terminal output port destinations that may include 
files and system character devices. Alternately, streams 

30 of text messages directed to the VCO terminal input port 
are interpreted as VCO commands and invoke standard VCO 
operations. This Terminal Stream Controller refers to all 
of the member functions and member data necessary to 
implement the terminal stream I/O mechanism in the VCO. 
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It contains three distinct parts that operate both 
independently and together, depending on the terminal 
operation. 

• Terminal Stream I/O Device controller is 

5 responsible for processing text messages sent 

to the VCO terminal input and output ports, 
in addition to managing the list of I/O 
devices . 

• Text Command Encoder /Decoder is comprised of 
10 two separate components: the encoder portion 

converts calls to the SCI into text-token 
string command representation used for remote 
VCO control, and the decoder parses an input 
stream of such text-token string commands and 
15 makes calls to the SCI as indicated by their 

format. 

• Linked Terminal Stream I/O Device List is a 
doubly linked list of all terminal I/O device 
objects that describe the identity and status 

20 for all character stream files, and devices 

to which text messages sent to the VCO 
terminal output port are written. 

Devi ce / Pro toco 1 Contr o 1 ler s 

This group of controllers serves to support the 
25 implementation of the logical operations invoked by calls 
to SCI member functions, as well as providing 
implementation of operations necessary to the 
establishment and maintenance of a connectivity session. 
The implementations of services in this VDI component 
30 must be only that portion of the given operations that 
can be supported in a fully device- independent manner. 

• Object Construction refers to all procedures 
and data structures involved in the 
construction of the VCO, including 
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initialization of all object: software 
components that do not control devices. 
Provides direct support for operations 
invoked by construction of the VCO by a 
client application. 

Object Destruction refers to all procedures 
and data structures involved in the 
destruction of the VCO, by its client 
application, including shutdown of all object 
software components • 

Configuration/ System Setup refers to all 
procedures and data structures involved in 
configuring the VCO according to its profile, 
previously saved on a backing store device. 
Also includes support for specialized audio, 
video, image, and binary data equipment setup 
utilities. Provides direct support for 
operations defined for the SCI 
Configuration/ System Setup Members. 
Binary Data Object Exchange refers to all 
procedures and data structures involved in 
the transfer of named binary objects, such as 
system files, to and from the remote station. 
Provides direct support for operations 
defined for the SCI Binary Data Object 
Exchange Control Members. 

Network Call State refers to all procedures 
and data structures to support a call 
controller compliant with that described in 
the section entitled Visual Call Progression, 
and consequently function to establish and 
maintain the connectivity session with the 
remote station. Provides direct support 
operations for internal VCO connectivity 
sessions. 
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System Information refers to all procedures 
and data structures involved with storage, 
retrieval, and maintenance of the various VCO 
parameter blocks, and their associated tables 
and lists. Provides direct support for 
operations defined for the SCI System 
Information Store/Retrieve Control Members. 
Capability Exchange refers to all procedures 
and data structures needed to support a 
structured exchange and comparison of device 
capabilities, as described in the section 
entitled Visual Call Progression. Provides 
direct support operations for internal VCO 
connectivity sessions. 

System Exception refers to all procedures and 
data structures involved in handling fatal 
errors that may occur in the VCO. Provides 
direct support for operations defined by SCI 
VCO Settings Members not shown in the 
drawing. 

Media control Object Access refers to all 
procedures and data structures involved in 
accessing the object-based device control 
system implemented in the PDI. Provides 
direct support for operations defined for the 
SCI Audiovisual/Data Signal Switching Control 
Members (that are not shown in the drawing.) 
Protocol Mode negotiation refers to all 
procedures and data structures involved with 
establishing a common set of parameters 
between the local and remote stations as 
described in the section entitled Visual Call 
Progression. Here also lies support for 
operations that will affect a specific 
conference profile as specified by the VCO 1 s 
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configuration parameters (or as set by the 
client application) ; includes support for 
operations essential to internal VCO network 
session implementation. 

5 Virtual! zat ion Layer 

Contains all procedures and data structures used 
to convert vendor- specific formats to those defined by 
the VCO. This layer also contains a number of controllers 
that are not always able to be implemented in a device- 
10 independent fashion , as some cognizance of vendor- 
specific peculiarities is frequently necessary to create 
a functional virtualization service layer. 

Event Controller 

Assigned responsibility for modulating the flow 
15 rate of device and software-generated events, in and out 
of an event queue. The queue acts a storage repository to 
record both the progress of operations carried forth by 
the VCO, as well as reports of new states and modes 
assumed by its underlying real-time device control sub- 
20 system. In general, devices and VCO controllers perform a 
mutually exclusive addition of events to an infinite 
sized event queue, in real time. A dispatcher removes 
them at a regular periodic rate, and disseminates them to 
an event processor, and to client applications desirous 
25 of knowing that one (of a particular set of events) has 
occurred . 

• Event Processor provides a structured 
mechanism for the VCO to respond 
appropriately to events generated by its 
30 device control sub-system. It maintains a 

number of feedback loops and procedures that 
are critical to enabling the VCO to 
adequately monitor and control its 
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connectivity session without assistance or 
monitoring by the client application. 
• Periodic Event Dispatcher checks the VCO 

event queue at regular intervals to determine 
5 if it contains any events. If there is at 

least one event in the queue, the dispatcher 
removes it (a single event) and invokes the 
Notification Controller to trigger any 
Notifier Objects that may be configured to 

10 respond to that event. 

• infinite FIFO Event Queue provides a 

sequentially-ordered cache for all events 
emanating from the device control sub-system 
or for events generated by software 

15 components within the VCO. It operates 

according to the first-in-first-out algorithm 
so that the original sequence at which the 
events occurred, is preserved through the 
event processing stage. Since the queue is 

20 constructed as a linked list of event 

records, it is capable of growing to a size 
limited only by the availability of system 
memory; thus events are never lost in any 
VMCS. 

25 • Critical Section Handler provides a mechanism 

to add events to the event queue in a 
mutually exclusive fashion. Also, various VCO 
operations that could result in resource 
contentions and deadlocks can utilize this 

30 component . 

Linguistic Controller 

Assigns textual labels to VCO events, states, 
operations, and a host of other functional entities, in a 
way that describes them using plain language. The role of 
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this controller is to enable VCO components to report the 
status of their operations in a readily-understandable 
format, rather than by the encoded strategies typically 
employed in computer systems. Various VCO controllers 
derive descriptive text messages from the labeling 
facilities offered here, and then send them to the VCO 
terminal output port. 

• Event Labeler Mechanism provides functions to 
return string labels for various VCO events 
of all types. In addition to returning text 
labels for the standard VCO notification 
events, this controller supports labeling for 
the generalized class of VCO events that 
includes all of the enumerated states, 
constants, modes, and string tokens 
representations of the arguments used by the 
Media Control Object Device Control 
Mechanism. The command encoder /decoder 
mechanisms also rely on the services offered 
by this component. 

• Object Component Labeling Mechanism provides 
labels for VCO objects and constructs that 
are used to report the current location of 
execution, or processing, in terms of the 
names of actual VCO components invoked. 
Contains the names of the VCO classes, 
controllers, an mechanisms that are used to 
formulate precise reports for debugging, 
diagnostics, and general troubleshooting of 
VCO components. 

• Event and Object String Label Database 
contains tables of text tokens and string 
messages accessed by the event /object 
component labeler mechanisms. 
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Device/Protocol Controllers 

The Device /Protocol Controllers for the VL and PDI 
layers, as shown in FIG. 3, represent the contribution of 
each layer in producing the virtualized multimedia 
5 connection services logically defined in the 

corresponding VDI controller (that occupies the same 
physical location on the drawing relative to the group of 
Device /Protocol Controllers) . This group of VL 
controllers serves to support the implementation of the 

ao device -independent procedures and operations supported, 
at their highest level, by the corresponding controllers 
in the VDI . As the VL controllers are specifically 
Virtualization Layer components, they serve to support 
the implementation of VDI controllers by providing any 

is necessary coercion of data format, command syntax, or 
interface method, from a vendor-specific modality, to 
that defined for the VDI. In many cases, the VL supplies 
a standardized function supporting a like standardized 
VDI function, but the embodiment of that in the VL is 

20 fully intended to be implementation-dependent. 

• Software Component Load/ Initialize provides 
implementation-dependent mechanism to load 
and initialize all supporting software 
modules, libraries, and device drivers 

25 necessary to VCO operations. Called by VCO 

constructor, the VCO construction fails if 
all necessary components are not present or 
fail to load. No devices of any sort are 
initialized or accessed explicitly here, 
' 30 except to determine if they are installed. 

• Software Component Unload/ Shutdown provides 
implementation-dependent mechanism to unload 
all supporting software modules, libraries, 
and devices drivers. Does not shut down 
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devices directly , but does free all resources 
associated with VCO. 

Configuration Information Access provides any 
necessary mapping of configuration 
information from/to the format used by the 
backing store method. Typically reads 
from/writes to a string-based initialization 
file and translates the string token format 
to that used by the VCO configuration 
parameters . 

Data Exchange syntax Happing provides mapping 
of file and record formats to that utilized 
by the connectivity protocol stack to that 
used by the host operating system. Examples 
include conversion of buffers and files 
to/from packet formats. 

Call Event Happing provides translation of 
vendor-specific connectivity protocol stack 
representation of call and line states to 
those used by the VCO call controller. 
System Information Happing provides 
translation of various vendor-specific 
representations of system information to/ from 
those used by the VCO, and enables 
translation of Media Control Object Device 
Control operations to H.221 device modes. 
Specific translation examples include call 
destinations, and media device states. 
Capability Happing provides translation of 
local and remote station H.221 capabilities 
emanating from the network protocol stack to 
those used by the VCO. Includes mapping of 
H.221 capabilities to Media Control Object 
capabilities . 
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• System Exception Mapping provides translation 
of various fatal errors from vendor-specific 
components to standardized VCO exceptions. 

• Media Device Driver Access Mapping provides 
5 translation of Media Control Object Device 

Control operations to Media Control Interface 
string commands that are presented to the 
Media Access Control layer. 

• Protocol Mode Mapping provides mapping of 
10 H.221 bit-rate allocation signal (BAS Code) 

indications used by the connectivity protocol 
stack (or emulated) to the device- independent 
representation used by the VCO. 



Physical Device Interface 

15 Contains all procedures and data structures used 

to interface device drivers and operating system 
resources directly. All implementations of functions are 
assumed to be device -dependent, and it is the principle 
objective of this layer to locate some form of physical, 

20 or emulated support to realize those operations logically 
defined in the VDI. If the PDI cannot provide, or even 
emulate, a service specified by the VDI, then it must 
return a result code indicating that it is not capable of 
doing so. 

25 Device/Protocol Controllers 

The Device /Protocol Controllers for the PDI layer 
represent the contribution of this layer in providing the 
physical interface component of the virtualized 
multimedia connection services logically defined in the 
30 corresponding VDI controller. This group of PDI 

controllers serves as the physical implementation of the 
corresponding operations managed by controllers in the 
VL. As the PDI controllers are specifically physical 
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layer components, they support the implementation of VDI 
controllers by directly accessing device drivers and 
vendor-specific library software components provided by 
third party OEMs; in the most efficient designs, the PDI 
5 may be implemented as an actual device driver, directly 
controlling hardware. 

• OEM Support Libraries and Drivers provide 
specialized ~t unctions, such as image 
processing, digital signal processing, data 

10 port interface, and system diagnostics, that 

are vendor-specific and usually hardware- 
specific, 

• Configuration Information Backing Store is 

the physical device that stores the VCO 
15 configuration information* Usually a file on 

disk and/ or some form of non- volatile memory 
device . 

• Connectivity Protocol Stack is the actual 
interface to the network, and includes all 

20 associated hardware and software components. 

The network service is presented to the VCO 
session components and transducers at the 
level of the OSI Transport Layer, whose 
responsibility it is to ensure reliable 

25 transfer of messages between end users. The 

Network and Data Link layers must be 
available, in some form, below the Transport 
Layer, and a physical or emulated network 
interface unit must be present and 

30 detectable. 

• Media Access Control provides physical device 
control mechanisms for input and output 
transducer devices in the system. This driver 
complement is used directly to implement the 

35 PDI's defined set of device control interface 
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functions used directly by the VDI, as well 
as by the Media Control Object Device Control 
Mechanism. 

• Device Capability List resides in the PDI as 
the master list of the all of the VCO 
capabilities. It is stored as an array of 
device- independent capability constants that 
reflect the range of H.320 (H.221) capability 
BAS codes. 

• Device Mode List resides in the PDI as the 
master list of the all of all possible device 
modes for any H.320 compliant station. It is 
stored as an array of device- independent 
device mode constants that reflect the range 
of H.320 (H.221) mode command BAS codes. 

• Media Control Objects (MCO) are constructed 
and maintained by the PDI, and presented to 
the VDI, as a method to control all signals 
to and from remote stations and transducers 
under VCO administration. The PDI interacts 
directly to support the device-dependent 
implementations that underlie these device- 
independent representations of 
audiovisual /data signals and devices as 

discreet system objects, each possessing a 

structured set of properties and well-defined 
operations . 

VCO SOFTWARE ARCHITECTURE 
System Dynamics 

It is useful to consider the VCO as a mechanical 
device, much like a spring-driven mechanical clock 
movement. Each VCO is a self-contained machine of 
interlocking parts, with a system timer interrupt 
advancing its works by the increment and released in 
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balanced measures that bring stability and smoothness of 
operation to the system's "top" end* The VCO's analogous 
"unwinding" takes place with the literal precision of a 
clock's escapement mechanism, in that the system timer 
5 serves as the regulatory entity releasing a steady pulse 
of queue-stored activities from the device control sub- 
systems, to a client application. A Virtualized 
Multimedia Connection System presents not only an 
idealized control mechanism to applications, but also 

10 idealizes the rate and content of the system's responses 
to these controls, without ever losing a system event, 
state change, mode change, exception or interrupt 
request. The overall VCO design is consistent with that 
of multi- threaded, queue-based device driver designs that 

is account for a significant portion of the dramatic gains 
in reliability and performance seen in the use of 3 2 -bit, 
multi-tasking operating systems such as IBM's Operating 
System/2 (see H.M. Deitel, M.S. Kogan, The Design of 
OS/2, Reading, Massachuetts, Addison-Wesley , 1992). 

20 Notes On Drawing 

FIG. 4 depicts an a detailed diagram of the major 
components and control flows of the Virtual Connection 
Object software architecture. The Device/Protocol 
Controllers shown are the same as those shown in FIG. 3, 

25 but the purpose in this drawing is to illustrate the 
direction of control flow through them, rather than to 
describe what they are. This discussion will examine the 
VCO in terms of its specific software mechanisms. To 
clearly show the functionality of individual VCO 

30 components in the two-dimensional drawing, it is 

necessary to alter their exact locations in the layering 
model from a perfect vertical orientation, to one more 
suited to revealing component interactive pathways. 
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Summary of VCO Software Architecture 

The software architecture of the VCO is can be 
described best in terms of two major functions: (a) 
controlling the multimedia connectivity sub-system it 
s encapsulates, and (b) responding to events emanating from 
it. What ensues is a brief overview of outstanding 
features that characterize the dynamics of the VCO 
software model. 

• The Software Control Interface (SCI) contains 
10 public member functions that enable a client 

application to access a consistent and 
logically-defined multimedia connectivity 
service to create a live audiovisual 
connections to a remote station. Calls to 

15 these members invoke the various 

Device/Protocol Controller services in the 
various VCO layers until some physical 
operation is eventually performed, the result 
of which is translated to logical, 

20 standardized result prior to being returned 

to the caller. 

• Each VCO contains a general repository for 
all system information that is continuously 
updated to reflect the current states of all 

25 controllers and devices. 

• Every VCO has standard input and output 
terminal ports that function much like the 
standard input and output devices in 
operating system shell console devices. All 

30 text message sent to the VCO terminal output 

port are written to a list of terminal I/O 
devices maintained by a Terminal Stream 
Controller. This controller also accepts text 
commands written to the terminal input port 

35 and decodes them, translating them to SCI 
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calls. An infinite FIFO event queue accepts 
the addition of events asynchronously, in 
real-time , by device control software, and by 
software components in the vco that generate 
their own particular events. 

An Event Dispatcher runs synchronous with the 
operating system scheduler (does not preempt 
the regularly scheduled time slices) to 
remove events from the queue at a constant, 
periodic interval and disperse them to a 
Notification Controller. 

The Notification Controller examines the 
dispatched event, dispensing notification 
information about the event via Notifier 
Objects that send the indication, and all 
associated information, to an event processor 
in the VCO (if the event is from a device), 
or to a client application object, depending 
on the Notifier Object's configured 
destination object. 

The VCO Device Event Processor invokes 
procedures to respond appropriately to events 
emanating from the device control sub- system, 
so as to maintain a connectivity session with 
the connected remote station. Call control, 
capability exchange, and various protocol 
operations are driven by the event processor, 
as is the issuance of text messages, 
describing all system activities, to the 
terminal output port. Host network events 
that require attention from the application 
in similar multimedia connection systems do 
not require such attention by VCO Clients; 
specific intelligences in the Device Event 
Processor component better direct them to 
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invocation of specialized internal procedures 
more suitable to such tasks, by their very 
designs — feedback loops often found in the 
application layer, reside in the VCO proper, 
alleviating the application developer from 
implementing sensitive protocol-specific 
modules • 

Ubiquitous throughout the VCO's controllers 
are reporting mechanisms that formulate 
detailed text messages describing the current 
state, mode, process, subroutine, class name, 
or event that is currently most relevant, and 
sending this string to the terminal output 
port. An Event and Object Labeler working in 
conjunction with a string database, has 
features that can assign text names and 
terms, in addition to maintaining a text- 
token definition of the VCO text command set. 
VCOs can link together across a connection to 
control or monitor the activities of the 
other station. This concept, referred to as 
attachment, utilizes a bi-directional text 
message stream to enable interconnected VCOs 
to share commands and events. Depending on 
the negotiated configurations of the 
"attached" VCOs, calls to member functions in 
the SCI of one, are encoded into text 
commands by the Command Message Encoder, and 
transmitted to the other station. Upon 
receipt, the Command Message Decoder 
translates the text commands back to SCI 
calls. Correspondingly, events queued at one 
station, as well as results of operations, 
are encoded by the Event Message Encoder, and 
transmitted to the other station. Upon 
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receipt:, the Event Message Decoder translates 
the text event messages back to events and 
adds them to the event queue, where they are 
dispatched along with a station identifier. 

5 Software Control Xnterface 

The Software Control Interface (SCI) consists of 
the VCO's public member functions and protected data that 
allow client applications to control the VCO. Any request 
for service using the SCI must pass a number rigorous 

10 examinations designed to reject any possibility of 

damaging the encapsulated sub-system. A client attempt to 
access a VCO member function results in an immediate set 
of verifications to determine if VCO is available for 
use, and if so, whether the context of the request is 

15 valid. For example, most operations require that the 
device control sub-system first be fully initialized. 
Arguments are checked for validity, and a text message 
describing the request is sent to the VCO terminal output 
port for tracing and monitoring purposes. If all 

20 conditions have been met, execution continues to the next 
level; progressing typically to a further request to the 
PDI. Rejected requests are turned away abruptly, but the 
client is compensated for his diligence, with a fair 
accounting of the dismissal; every operation returns a 

25 concise result code. 

Member Functions 

Member functions to invoke the services of the VCO 
are partitioned into several distinct categories. The 
members and their arguments are highly structured and 
30 flexible in the variety of ways they may be utilized. 
They are easily mapped to a text-token command set. All 
of the members of this interface are available from one 
constructed VCO, and each optimized to best support the 
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likely use of it, rather than providing similar access 
methods for all command permutations equally. The 
pathways through the VCO layers and components are unique 
for each functional group, and are summarized briefly: 
5 • Event Notification Control Members make calls 

to the Notifier Object List Manager to 
create, delete, and configure, and trigger 
Notifier Objects in the Linked Notifier 
Object List. Calls to trigger notification 
io invoke the Notification Triggering Mechanism 

directly. 

• Terminal Service Control Members make calls 
to the Terminal Stream I/O Device Controller 
to add and remote devices from the Linked 

15 Terminal Stream I/O Device List. Calls to 

send text messages to the terminal output 
port are made through this object, as are 
calls to send text command message to the 
terminal input port for decoding and 

20 execution. 

• Configuration/ System Setup Control Members 
make calls to the PDI to store and retrieve 
configuration information from some physical 
backing store device. 

25 • Network Session Control Members make calls to 

the PDI to initialize and shutdown the 
encapsulated multimedia connectivity sub- 
system, as well as to initiate and terminate 
sessions with a remote station. 

30 • Audiovisual/Data Signal Switching Control 

Members make calls to the PDI to manipulate 
audio, video, image, and data objects that 
comprise the Media Control Object Device 
Control System of the VCO. 
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• Binary Data Object Exchange Control Members 

make calls to the PDX to transfer binary data 
objects and data buffers to and from the 
remote station . 
5 • System Information Store/Retrieve Control 

Members make calls that access the VCO system 
information repository in a structured 
manner; a manner which does not allow for any 
direct modification of VCO data structures, 
10 • Protocol Management Control Members make 

calls to the PDI to directly set H.23 0 device 
modes, send capabilities to the remote 
station, and perform other protocol related 
tasks . 

15 Terminal Service 

The VCO terminal service has two main pathways: 
into the VCO through the terminal input port, and out of 
the VCO through the terminal output port. Alternately, 
when the terminal ports are considered as standard input 

20 and standard output devices for the VCO, it is sensible 
to view the two modalities as a stream "to the terminal" 
and "from the terminal". 

• Output Streams to VCO Terminal originate from 
the VCO itself, or from client applications. 

25 Messages "to the terminal" are directed to 

the terminal output port and dispersed, via 
write operations, to output devices (attached 
to the terminal output port). Summary, "To 
terminal" is synonymous with ■ to text output 

30 devices." 

• Input Streams from VCO Terminal originate 
from outside the VCO, typically from a dumb 
terminal or client application wishing to 
control it with text commands. SCI calls 
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sending text messages as if "from the 
terminal" are directed to the terminal input 
port and interpreted as input text command 
messages, as if input from a keyboard. 
Summarily, "From terminal" is synonymous with 
"from the standard text input device." 
Terminal Stream I/O Device Controller 
maintains a linked object list of output 
device objects to which the text message sent 
to the terminal output port are written. All 
text messages sent to the terminal output 
port are written to every device cataloged by 
the linked object list. Output devices 
include system files, character devices, and 
Notifier Objects created for the transmission 
of text message to objects. 



system Information Handling 

System information is fully protected from direct 
external access the vco, though all internal components 
20 can access it directly. Clients must us specific member 
functions to get a copy of the data, and use other 
members to affect changes to it through structured 
operations. Internally, all system parameters are fully 
accessible to all components derived from the VDI. 
25 • Configuration Parameters store the current 

copy of VCO configuration and system setup 
information that is read from backing store 
at VCO construction time. Contains 
information about the network service 
30 available, and all system defaults. The 

parameters can be modified and written back 
to backing store at any time. 
• Device Parameters store all settings and 
parameters related to the 
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audio/ video/ image/data devices installed in 
the sub-system, and retain handles to the 
current source, destination, input, and 
output signals affected by the Media Control 
Object Device Mechanism. 

Call Parameters store all of the current call 
and line states, including those for 
multipoint calls. Maintains records about 
other stations in the conference. 
Protocol Parameters store all current 
transmit and receive modes for all the 
various data types. 

Control Prameters stores all information 
related to maintaining the remote station 
control mechanism for any attached station. 
Monitor Parameters store all information 
related to maintaining the monitoring access 
for any attached station. 

Notification Mechanism 

20 The VCO notification mechanism conveys an 

indication that a particular event has occurred by 
activating, or "triggering", a notification entity 
referred to as a Notifier. Maintained in a list internal 
to the VCO, Notifier Objects are created specifically to 

25 call a member function of some appropriately enhanced 

class object, somewhere in the system (within or without 
the address space of the VCO) when triggered. Upon the 
VCO event dispatcher's presentation of an event to the 
Notification Controller, Notifier Objects in the list are 

30 systematically examined, and potentially triggered, 

according to a specialized modality of governance that 
considers the relationship of the outstanding event type 
(among other parameters) to the triggering profile of the 
Notifier Object itself. 
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Notifier Objects (NO) 

These objects comprise the basic indication unit 
of the VCO notification mechanism. Each NO is an instance 
of a class object that may be created by a VCO client , or 
5 the VCO itself, and configured to "trigger" in response 
to the occurrence of any one of a set of VCO events. Each 
NO is associated with a specified Notification Receiver 
Object (NRO) to which the trigger response is directed. 
When an NO triggers, it makes a function call to the 

10 associated NRO member function assigned to the task of 
handling notifications. Passed to the NRO is an event 
identifier, and a number of qualifying arguments that 
describe the context of the event's occurrence. There are 
two mutually exclusive modalities for any NO; they can be 

is configured to respond to any event, or configured to 
respond only to events emanating from VCO-encapsulated 
devices • 

Notifier Management 

This task is handled by the Notifier Object list 
20 handler. This component adds to, removes from, and 

maintains the integrity of the Notifier list. It also 
provides members for configuring Notifier Objects with 
new trigger response profiles, as well as to allow them 
to be enabled, disabled, and examined for statistical 
25 information. In the VCO, the notification mechanism is 
supported by a component that manages the list of all 
active Notifier Objects, and a triggering mechanism that 
determines as to whether or not an individual Notifier 
should trigger, based upon the occurrence of an event to 
30 which it is configured to respond. 



Triggering Mechanism for Notifier Objects 

This mechanism conditionally determines as to 
whether or not a Notifier Object should trigger, based 
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upon a specific algorithm. Notif ier Objects can be 
configured to respond to events that emanate from the 
device only, so as to direct their trigger response to 
the VCO Device Event Processor. Through this method, the 
5 VCO uses Not if ier Objects internally to create a direct 
pathway for device events (added to the VCO queue by the 
device) , to be processed in the VCO Device Event 
Processor exclusively. This distinction serves to prevent 
an infinite loop that would result if the VCO processes 

10 an event from a device, and then reissues (requeues it) 
it so that client applications can be subsequently 
notified of the same event — the same event would be 
dispatched back to the event processor again and again if 
reinterpreted as another occurrence of the same device 

15 event. Thus a distinction must be made between the 

original device event and a processed derivative of that 
same event intended for dispatch to the client 
application. Motifier Objects configured to trigger on 
events directly from devices will only trigger on events 

20 directly from devices. When the event processor reissues 
the event from the device, it marks it to indicate it is 
not directly from a device, and it can no longer trigger 
the Notif ier that would send it to the Device Event 
Processor . 

25 Notification to Clients 

VCO Client applications may request notification 
of a combination of VCO events by creating a Notif ier 
Object and configuring it to trigger when any single 
event in the combination actually occurs. Once created, 
30 the Notif ier Object conveys event notification to an 

application object set to that purpose. The object that 
receives notification is referred to as a Notification 
Receiver Object (NRO) . 
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• Notification Receiver Objects (NRO) receive 
function calls from an entity in the VCO that 
is created specifically to direct 
notification of the occurrence of an event to 

5 them. A class object can serve as an NRO if 

it contains a special Notification Receiver 
Member and an attendant thunk. The thunk is a 
globally accessible function that is created 
to receive notification from the VCO and 

io redirect that notification to the NRO's 

Notification Receiver Member. In this way, a 
VCO can deliver a notification message to a 
class object which can then directly access 
other class members and member data that 

is would not be available if the notification 

was to a non-member function i.e. had to 
access class members with a special class 
pointer . 

• Notif ier Triggering Profiles refer to the set 
20 of events to which the Notif ier Object is 

configured to respond. Notif ier Objects are 
"triggered" to notify their associated NRO 
when one of these configured events occurs. 



Even t Ha ndling Mechanism 

25 The event handling mechanism consists of three 

concurrent, but distinctly separate processes. From the 
perspective of any single event, these processes occur in 
a serial fashion. First, events are added to the trail of 
the VCO event queue by various VCO components. Next, a 

30 concurrently executing event dispatching process 

periodically removes an event from the queue. Finally, 
the event dispatcher sends the removed event to the 
Notification Controller where it triggers Notif ier 
Objects configured to respond to events of this 
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particular type. If the event is a device event, and the 
Notifier is configured to respond to device events, then 
its Notification Receiver Object receives notification 
that the event has occurred. If the event removed by the 
5 dispatcher is some derived event, it may trigger 
notifications to client application, or any other 
Notification Receiver Objects targeted by a Notifier 
responding to that event: 

Device Events 

10 These events are generated directly by a device in 

the encapsulated sub-system; a situation that potentially 
requires some kind of immediate responsive action. They 
are the primary responses from VCO devices and emanate 
from network and media control driver software 

15 components . 

Derived Events 

These events are generated by a VCO software 
component, and are derived from an action or logical 
state, not directly emanating from a device. They are the 
20 secondary responses from the VCO itself, often resulting 
from the processing of device events* 

Event Processing 

The task of event processing includes the handling 
of both Device Events and Derived Events. Device events 

25 can only trigger Notifier Objects configured to respond 
to device events, thereby enabling a particular Notifier 
Object to function as a dedicated device event notifier. 
Events entering the Device Event - Processor are typically 
line state changes, device mode changes, and indications 

30 from the remote station. These events drive protocol and 
session management routines during processing, which in 
turn generates derived events such as the call state 
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changes and Media Control Object Device Control parameter 
changes* These derived events are queued for subsequent 
dispatching to client applications; these secondary 
occurrences are treated differently from primary events 
5 in that they will not be handled by the Device Event 
Processor* 

Event Dispatching 

Dispatching of events occurs periodically at a 
programmed rate that may be adjusted dynamically at run- 

10 time* Typically, dispatching five events per second is 
sufficient to present the client application with a 
manageable stream of events. The event dispatcher is 
driven by a system timer interrupt. If the queue is 
available for mutually exclusive access, it is checked to 

15 determine if there are events in it. If there is at least 
one event in the queue, one event is removed in a 
critical section, and the queue is released to the 
system. If mutually exclusive access is not immediately 
available, or there are no events in the queue, the 

20 dispatcher yields* Otherwise, the removed event is next 
presented to the Notification Controller where any 
Notifier Objects in its list, sensitive to the event, are 
triggered so as to disperse the event throughout the 
system ■ 

25 Event Queuing 

Queuing of events occurs sporadically, when an 
event is generated by a VCO-encapsulated software or 
hardware component. Frequently occurring during hardware 
interrupt cycles, queuing is carefully optimized to 

30 require very f ew cycles and little resource allocations. 
A short blocking operation may be necessary during 
dispatching to gain mutually exclusive access to it. The 
event is added and the queue released back to the system. 
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If the atterpt to add an event to the queue fails, a 
fatal error (VCO Exception) occurs and the VCO is 
permanently disabled. 

Exception Handling Matters Mechanism 

5 The VCO exception handling mechanism is not shown 

in FIG. 4. Exceptions in the VCO are conditions that are 
deemed fatal errors from which the system cannot recover 
vithout risking a system crash. The underlying design 
principle to VCO exception handling is that system 

10 crashes result most often from continued use of a 

destabilized system component, from attempts to recover 
from destabilized conditions, and from the failure of a 
destabilized system to acknowledge its "time-bomb" 
status. In accordance with an overriding concern for 

15 system reliability, VCO exceptions generate reports, and 
a subsequent disabling of the VCO. Neither the VCO, nor 
its concomitant support software, is accessed until the 
VCO is destructed. Once disabled, all calls to the SCI 
return immediately with a result code indicating that the 

20 VCO has been disabled. For continuous use applications, 
the risk of system crash is rendered unlikely, and the 
system witti one destabilized sub-system likely remains of 
SUrticient health to invoke a resident backup system. 

Fatal errors occurring internally to the VCO 

25 generate an internal assertion failure that invoke a 

recovery routine that proceeds to execute a reverse stack 
trace. The trace searches for markers pushed onto the VCO 
stack during calls to a special member function called 
upon entry into the VCO. Every VCO entry point is guarded 

30 by a call to a function that returns a result code 

indicating whether or not the VCO is enabled or disabled. 
Upon locating the address of the instruction pointer (on 
the stack) at the execution point of this status call, a 
result code indicating that the VCO is disabled is pushed 
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onto the stack, along with the address of the entry 
point. A return instruction is executed to bring the 
calling thread back to its original point of execution 
just prior to calling the VCO status member (which will 
5 indicate that the VCO is *unava liable" when the status 
call is re-executed) , and to the impression that it has 
been turned back at the door due to a preexisting 
disabled state. The calling thread is without cognizance 
of the fatal error it unwittingly generated by its 

10 venture inside the VCO, and finds the VCO is simply 

unavailable for continued use. This technique of shutting 
down the damaged VCO, accompanied by transparent error 
handling (from the perspective of invoking applications) , 
maintains system integrity until the host system can risk 

is a recovery operation. 

Exception Handler Modalities 

A variety of VCO exception handling modes can be 
invoked incrementally by specifying any combination of 
the following modality flags. These modalities are 
20 additive, and affect the way in which reporting of the 
exception is handled. 

• Debug modality flag, if set, specifies that, 
detailed debugging information (in a message 
box) will be displayed at the time of 

25 exception. This mode is intended for use 

during system development where proprietary 
information will be displayed. 

• User modality flag, if set, specifies that 
general "user" information (in a message box) 

30 will be displayed at the time of exception. 

This mode is intended for use in the field 
after the product is released. 

• Term modality flag, if set, specifies that 
exception information will be sent to the VCO 
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terminal output port for display on terminal 
output devices. 

• Notify modality flag, if set, specifies that 
the exception will generate an exception 

s event and trigger Notifier Objects prior to 

disabling of VCO. 

• Abort modality flag, if set, specifies that 
the exception will abort all VCO operations, 
after reporting the exception, and disable 

10 the VCO. 

Event and Object Labeling Mechanism 

This mechanism provides function calls that 
convert indexes to strings. It relies on a collection of 
string tables, whose string element positions reflect the 
is value of the indexes. The string tables can be loaded 

from resource files that contain text in the appropriate 
language . 



Labeling of Events, Enumerated Values and Result codes 

Retrieving a text label to describe a VCO event is 
20 accomplished by presenting a VCO event identifier, result 
code, or standard enumerated constant to the appropriate 
member function. A pointer to a static copy of a null 
terminated label is returned, and is typically used to 
formulate messages for terminal output, and by 
25 applications to display states, modes, and operations 
taking place in the VCO. 

Labeling Objects 

Retrieving a text label for a VCO software object 
is accomplished by presenting a pointer to the object to 
30 a member function. A pointer to a static copy of a null 
terminated label is returned, and is typically used to 
formulate messages for debugger and trace window output. 
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Used specifically for debugging, diagnostics, and 
-troubleshooting . 

Event and Object String Label Database 

5 A memory resident database in the VCO contains 

tables of string records for all of the VCO enumerated 
constants, and the VCO command set. Reference databases 
containing object pointers and labels are created at VCO 
construction time. 

10 Media Control Object Device Control Mechanism 

Designed to facilitate the manipulation of signals 
as distinct objects, this device control method is 
intended for full implementation as a graphical desktop 
media control system, supporting a drag and drop signal 

15 switching model. Each object, representing a specific 
signal type, has a standardized set of properties, and 
well-defined modes of interaction. The physical structure 
of the Media Control Object Device Control Mechanism 
represents each signal as a software class object, and 

20 all signals currently available in the system as a linked 
list of such objects in the VCO DEVICEPARAM structure. 
Media Control Objects are created and deleted as signals 
become available, or unavailable, depending on connection 
state and device availability. 

25 VCO signals are identified according to their type 

and direction. The possible types of signals include 
audio, video, image, and binary data. The possible 
directions include input from the remote station, output 
to the remote station, input from a local transducer, and 

30 output to a local transducer. Member data in each Media 
Control Object describe the current states and modes 
related to the signal. Member data in each Media Control 
Object describe the current states and modes related to 



WO 98/09213 



PCT/US97/15018 



- 79 - 

the signal, and member functions invoke physical 
operations in their host devices. 

It is possible to determine if a given Media 
Control Object is capable of specific operation by 
5 setting the query flag on the SCI member function to 
control them. In this manner, the client can test an 
operation without invoking it. A special function to 
return the capabilities of a setting is also available, 
and a list of settings constants (or parameters for the 

10 setting) is returned. For H.221 capabilities, related to 
the multimedia interconnection protocol, the VCO 
parameter block maintains an updated listing. There is a 
very close logical mapping between H.221 capabilities and 
Media Control Object capabilities — no H.221 video mode 

15 means that there is no motion-video available — and it 
is likely that the very existence of a Media Control 
Object indicates that most of the operations for that 
signal type are supported to some degree. It is often 
sufficient to let a client attempt to set the mode, and 

20 report that the system is incapable, than to constantly 
monitor and maintain a local capability listing* 

Device/Protocol Controllers 

The divers Device /Protocol Controllers, discussed 
in the overview section, each have emulation components, 

25 shown in FIG. 4, that reside in either /both the VL and 
the PDI. The objective in any VCO emulation mode is to 
enable to the VDI to operate fully, without the ability 
of it, or any client applications, to differentiate 
between operation with actual device support, or 

30 emulation of it. There is an emulation mode flag in the 
system information that determines the operating mode. 
Any operations supported in the VL or the PDI must check 
this flag during every invocation of service, and either 
access a physical device, or provide a set of results 
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indistinguishable from having done so. No support for 
emulation of operations exists in the VDI ~ it makes no 
direct references to low-level device services except 
through the PDI. 

Remote Station Attachment Mechanism 

Attachment of a remote station to the local 
station enables the local station to monitor its event 
stream and control its operations. The basic mechanism of 
attachment has been discussed in general, however the 
specifics of this interaction deserve more attention. 
Essentially, an attachment mechanism sufficient to 
monitor a remote station requires a cross- linking of the 
output of one station's event encoder to the other 
station's event decoder. To establish control of a remote 
as station, there must, in addition, be a cross-linking of 
the output of one station's command encoder to the other 
station's command decoder. There are a number of 
operational considerations that become the subject of 
negotiation between the stations, once attachment is 
20 accomplished. 

Monitor context 

Monitoring context refers to the station that is 
the source of the current event stream emanating from the 
local vco's dispatcher. Any combination of the monitoring 

25 modes can be in effect once attached. A VCO that is not 
attached to a remote station can only monitor local 
events. The remote station must grant permission to be 
monitored by the local station by indicating so in its 
monitor parameters. VCO monitoring modes are described as 

30 follows: 

• Local monitoring mode affects the target VCO 
to dispatch and process events local to it. 
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• Remote monitoring mode affects the target VCO 
to dispatch and process events emanating from 
the remote station to which it is currently 
attached . 

5 • Array monitoring mode affects the target VCO 

to dispatch and process events from a 
specified array of remote stations. 

Control Context 

Control context refer to the station that is 
10 controlled by calls to local VCO SCI member functions. 

The remote station must grant permission to be controlled 
by the local station by indicating so in its control 
parameters * VCO control modes, from the perspective of 
the local station, and when set in the physical local 
15 station VCO, are described as follows: 

• Master control mode enables the local station 
to control a remote station to which it is 
currently attached. 

• Slave control mode enables the local station 
20 to be controlled by a remote station to which 

it is currently attached* 

• Peer control mode enables both the local and 
remote stations (attached to each other) to 
control themselves, but not each other. This 

25 is the standard operating mode for most 

interconnections between stations* 

CLIENT SOFTWARE ARCHITECTURE 

FIG. 5 depicts a VCO client application; arrows 
highlight the flow of function calls through its various 
30 components. The diagram shows a full implementation of a 
VCO client application that best describes the VCO Client 
application concept. All of the components shown are not 
necessary to establish a minimally-functional multimedia 
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connectivity session with a remote station, but are 
needed to make full use of the entire VCO feature 
complement. The client application specification, unlike 
that for the VCO itself, is represented in a generalized 
5 fashion, and strict compliance is not necessary to 

achieve the benefits touted by the VMCS; a broad range of 
effective application designs may be derived from this 
prototypical VCO Client application model illustrated. 

Summary of Client Software Architecture 

10 A client application selects a class library 

supporting an implementation of class VCO* Constructing 
class VCO, it makes calls to the Software Control 
Interface for the newly invoked VCO to establish a 
connectivity session with a remote host. The client has a 

15 number of components that it uses to manage this session: 

• The Device- Independent Connectivity 
Application Shell provides the user- interface 
and basic task management for the client 
application. This component displays session 

20 status information, and initiates the 

milestones of its inception and termination. 
This component is the logical control 
mechanism for all VCO operations. If it is to 
construct a VCO directly, it must be created 

25 with the same object-oriented language as the 

VCO itself. While it is preferred that the 
client is a GUI application to best present 
the VCO control system to the user, it can be 
as simple as a daemon running in background, 

30 that processes string commands from a data 

stream directed to it. 

• A number of Notification Receiver Objects 
receive notifications from the VCO that 
various VCO events have occurred. Client 
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applications typically create a Notif ier 
Object to receive text streams from the VCO 
terminal output port. At least one other 
Notif ier Object should be created to receive 
indication of the three major classes of new 
local station modes (new H.221 transmit 
modes), new remote station modes (new H.221 
receive modes) , and new call state changes 
(new call and line states) — one Not if ier 
Object can be configured to respond to all 
three of these event types. 
Event emd Text Processing Components are 
specifically designed to analyze and/or 
respond to text and event information 
emanating from the VCO. Text processing of 
the terminal output stream can take the form 
of graphical display in a trace window that 
has the facility to enable its viewer to move 
forward and backward through the output 
messages, in order to view the progress of 
the session. Trace information could also be 
saved to a log file to permit later analysis 
of session activity. Finally, trace output 
can be analyzed by a debugger, or H.320 
protocol analyzer. New remote station modes 
are usually routed to the Station -Prof ile 
Controller for processing and interpretation. 
The Station Profile Controller examines new 
modes set by the remote station, and using a 
Station Profiler, compares them to a 
database, to determine the remote station's 
manufacturer or type. Once identified, the 
remote station's profile is elicited from 
that same database, and its non-standard 
feature set made available to the 
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application. Non-standard features include 
advanced camera control operations, 
proprietary VCO features, data exchange 
protocols, and application sharing features. 
Non-standard capabilities are also examined 
to determine the level of functionality, of 
which the remote station is capable. The Non- 
standard H.221 Mode Mapper provides a 
virtual ized representation of the remote- 
station's available special features, and 
presents them to the application shell in a 
manner conducive to their mapping to local 
station physical controls. 

Application Notification 

In the general sense, a stream of events flows 
from the VCO to the client. Ongoing notification of the 
application, by the VCO, in the form of multiple 
concurrent event streams delivered to application class 
objects, changes the context of the VCO from a sub-system 
invoked by the client, that returns values in response to 
commands, to an adjunct connectivity operating system; an 
operating system running in parallel with the primary 
operating system, actively communicating with its client 
application processes through an interrupt -like 
mechanism, and similarly operating completely 
independently to specifically manage system multimedia 
connectivity resources. 

Notifications from the VCO, to its client 
applications, take place using a mechanism designed to 
provide structured entry points that function much like 
interrupt service routines. From the perspective of the 
client, the design eliminates the risk of interfering 
with the delicate timing of the underlying multimedia 
connectivity sub-system, and does not confound normal 
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time slice allocations by the operating system scheduler. 
At the level of the application, notifications are 
discreet entities that are independent of any operating 
system or GUI event processing/queuing schemes, and 
5 resultant ly more time-responsive; so much more responsive 
than adding events added to the application event queue, 
that notifications can preempt drawing operations by the 
GUI, but without inordinately starving the GUI of its 
time slices. The notification is usually implemented to 

io run on a separate thread, concurrent with those drawing 
on the display, and thus connectivity events can be 
processed concurrent with drawing, rather than subsequent 
to a GUI operation in progress. The VCO Client 
notification system permits the design of high- 

15 performance, multithreaded applications that can process 
and respond to connectivity events with responsiveness 
that (in the context of a user interface) approximates 
real-time. Notification to VCO client applications, 
proceeds with rapidity such as is required for 

20 controlling both local peripheral devices, and the 
peripheral control features of remote stations, while 
concurrently maintaining a responsive graphical desktop 
display. 

Notification Receiver Objects 

25 In the application, any class object can be 

configured to receive calls from a Notifier Object when 
any one of a subset of events occurs. A member function 
in the object is declared for this purpose by the 
creation of a thunk. As previously described, thunks are 

30 created to redirect calls from the Notifier Object in the 
VCO, from a public global non-member function in the 
application (called by the Notifier Object) , to the 
particular class object instance and member function 
intended exclusively for the purpose of notification. The 
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receipt of notifications by the application often results 
in the application's issuance of calls back to the VCC to 
correct, compensate, or respond to the condition. Many 
event handlers in the application function as feedback 
5 loops; upon notification, they immediately invoke VCO 
functions in response • Logical assistance by the client 
application is unnecessary once appropriate response 
routines have been setup - the VCO manages the multimedia 
connectivity system automatically. 

10 Station Profiling 

The primary objective of the client station 
profiling mechanism is to first identify the remote 
station as one represented in a local database of 
potential remote station types. Once a descriptor for the 

15 remote station is found in the database, the client can 
now determine any non-standard device modes (that invoke 
special features) supported by that remote station. 
Further, a list of corresponding non-standard 
capabilities is also stored in the descriptor, such that 

20 the local station can make a positive predetermination as 
to whether the special feature associated with the remote 
station type, is actually available for use. Nonstandard 
modes supported by the remote station can then be mapped 
to leea^-controls so that the VCO client becomes capable 

25 of a degree of station control typically only possible by 
interconnection between two stations from the same 
manufacturer - VCO stations can fully understand the 
particular proprietary non-standard features they 
support. The VCO client is capable of an extraordinary 

30 degree of compatibility with an unlimited range of remote 
stations. 
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Station Profile controller 



This software controller contains three components 



that provide the functions necessary to implement a 
transparent mapping between local station controls, and 
5 remote station non-standard features. Local station 
features, beyond those represented in the VCO control 
mechanism have specific sequences of device modes that 
must be set to activate them. Non-standard modes on the 
remote station work the same way, except the mode 
10 sequences are different. The three components of the 

Station Profile Controller enable the client to associate 
any local or remote station non-standard feature (mode 
sequence) with a control on the local station. In short, 
the Station Profile Controller offers a symbolic, device- 
is independent representation of local and remote station 
non-standard features, and beyond that, the ability to 
associate one local with one remote. An example of this 
association is in order: consider a surveillance system 
that maintains two specialized features: 
20 1) It allows an operator to remotely select the 



35 



30 



25 



2) 



current camera from a variety of available 
input cameras. 

It displays an M X M cursor on the operator 
station video image, pinpointing the exact 
center of focus for its currently selected 
camera, and the remote station will move its 
selected camera to correspond to any mouse- 
invoked change in the cursor location on the 
operation display, therein allowing the 
remote operator to survey the area with 
simple mouse movements. The remote station 
will continuously reflect the camera's actual 
physical position by rendering a cursor on 
the operator station visual display. There 
is no H.320 representation of these 
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operations, beyond support for sharing a 
cursor position; the selection of a remote 
camera is a simple operation, but the second 
feature is one complex, proprietary, and in 
5 need of specialized library support features 

— the cursor movement mechanism requires a 
complex feedback mechanism to move and 
display the n X" cursor as intended by the 
remote station's programming. When the 

io operator station connects to this monitor 

station, the operator station determines that 
the remote station is of this particular 
monitoring station type, and locates a 
descriptor in its database that describes it. 

15 The modes to select the camera are 

represented symbolically to the VCO client, 
and mapped to local station controls. The 
sequence of mode-setting operations necessary 
to the selection of the remote station camera 

20 is invoked by offering the symbolic 

representation of the operation to the 
Station Profile Controller. For the more 
complex cursor-aiming feature, incoming 
cursor position modes are mapped to a 

25 virtualized definition of cursor movement, 

and passed to functions in a library of 
supporting routines, developed specifically 
to display it as required. Local station 
mouse movements over the video display 

30 region, on the operator station's bitmapped 

display, are mapped to cursor movements sent 
to the remote station via a similar mechanism 
used for camera selection. It is the VCO's 
notification mechanism that enables the 

35 concurrent processing of device modes. 
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sending and receiving -them to/from the remote 
station, at the system level of the GUI 
application, without interference from other 
application activities . 

5 Station Profiler 

This component is responsible for identifying the 
remote station. Upon connection, it sets sequences of 
modes, and conducts whatever query is necessary to 
determine its manufacturer. To this end, it compares 
10 modes sent back from the remote station to stored 
sequences in the database. 

Non-standard Mode Mapper 

This component maps non-standard local modes, to 
specific features, by assigning mode sequences (and 

is function calls) to an intermediate symbolic 

representation, which is then used in a feature mapping 
table. The same mapping is performed for non-standard 
remote station modes, however the mode sequences are 
preprogrammed, stored in a database descriptor, and 

20 selected according to the identity of the remote station. 

Non-standard Capabilities Mapper 

This component manages the capabilities associated 
with the non-standard modes handled by the non-standard 
mode mapper. It provides a mechanism to determine if non- 
25 standard modes are available on the remote station, as 
well as mechanism to inform the remote station that the 
local station is capable of handling its non-standard 
modes . 

CLIENT VCO ACCESS METHODS 
30 Derived from this design are several methods for 

VCO Clients to access the services of the VCO, so as to 
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make use of the VCO as an independent multimedia 
connectivity operating system that supports client 
sessions. 

Notes On Drawing 

s FIG. 8 depicts the various methods used by VCO 

Clients to access service of a particular VCO. The left 
of the drawing, labeled "REMOTE SYSTEM", and the right, 
labeled "LOCAL SYSTEM" , should not be confused with the 
"REMOTE STATION" or "LOCAL STATION"; access from another 

10 system may be from any computer supporting a text command 
stream to the host system, even from a dumb terminal. If 
the controlling system is a "STATION" (connected across 
the network) , then it must establish a text data stream 
(in— band or out-band) to transceive VCO commands between 

15 the two systems. Note that the VCO depicted in the 

"REMOTE SYSTEM" is controlling the local system as its 
master, by employing some command dispatching mechanism 
to connect to the local station, but not necessarily over 
the network. 

20 summary of Access Methodologies 

The services of VCOs are utilized by client 
applications that construct them, and subsequently make 
calls to their member functions. Once constructed, the 
VCO lies resident in the host system as an adjunct 
25 multimedia connectivity operating system that can respond 
to requests for service, when accessed in one or more of 
the following ways: 

• Client applications running in the host 

system are able to construct one, or more, 
30 VCOs through the usual Direct Member Access 

method; that is, they call member functions 
in the VCO's Software Control Interface, to 
drive a multimedia connectivity session. 
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To provide text command access from a remote 
system, without sending commands across a 
network connection, a VCO/TTY Access Daemon 
can construct a VCO in a host system, and 
then open a command text stream through a 
system communications port. Any remote system 
connecting to that port can send commands, 
and examine the effects of their issuance. 
A VCO terminal session is established upon 
connection to a remote system communications 
port that is being monitored by a VCO 
directly, or monitored by an Access Daemon. 
From the perspective of the remote system, 
the method of creating a terminal session to 
control a VCO, is referred to as Remote 
Command Access. Simply put, VCO commands are 
issued directly from a remote station or dumb 
terminal, to a waiting VCO, or daemon acting 
on its behalf. 

A seamlessly integrated remote VCO control 
solution, referred to as Remote Member 
Access, is an access method that creates, in 
a VCO implementation, a Media Control Object 
that is expressly designed to establish a bi- 
directional text data stream through a 
particular system port. The VCO command/ event 
streams are directed through it, to provide a 
level of control that allows a VCO client, 
invoking VCO members on its own local system, 
to drive a remote VCO transparently. This 
method utilizes the identical components and 
mechanisms as for remote VCO control across a 
connection, except that the command/ event 
stream is directed to an out-band 
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communications port, 
network connection. 



and not the principle 



IMPLEMENTATION 

This section describes the full implementation 
5 of a VMCS that supports concurrent live audio, live 
video, imaging, and binary data transfer services. The 
VCO portion of the system must be created to support the 
specific configuration of devices installed. Compliant 
client applications will run over any VCO that they 

10 construct. Any number of VCOs can be created to 

encapsulate divers combinations of devices installed in 
the system. An instance of a VCO (that encapsulates a 
device set) is one of many possible presentations of that 
same device set to an application; a different VCO 

is implementation may invoke the same devices in a different 
way, or using different drivers (for example) to present 
an entirely different performance profile. Depending on 
the capabilities of the sub-systems installed, multiple 
VCOs can be instantiated concurrently to provide multiple 

20 multimedia connectivity sessions at the same time. There 
is no limit to the application of the VMCS paradigm, as 
long as the specified VCO service is provided, through 
some means, to the client application or marked as absent 
in the VCO's capabilities listing. 

25 VMCS HOST SYSTEM REQUIREMENTS 

Implementation of a VMCS is best accomplished in a 
microcomputer host system equipped with peripheral 
devices to process audio and video signals, and a 
connection device to interface with the network. A VMCS 
30 can be constructed to run over almost any combination of 
the components discussed in the section entitled Host 
System Equipment Requirements below, depending on the 
level of implementation desired; support for concurrent 



WO 98/09213 



PCT/US97/15018 



- 93 - 

audio, video, image, and data services is hereupon 
described for the disclosure of full VMCS implementation, 
but any partial implementation is possible without 
affecting the basic VMCS design. The VMCS is ideal for 
5 limited usage i.e. only for audio connectivity. 

Furthermore, the bewildering array of devices for audio, 
video, data, imaging, and videoconferencing, that are now 
available, often combine the functionality of two or more 
devices, in which case the perceived differentiation 

10 between them exists only in the software abstraction 
layers that comprise a VCO. For example, an audio and 
video device may be combined on one board, but will 
appear as (map to) a number of discreet functional Media 
Control Object entities, whose hardware support mechanism 

15 is indeterminate, when considered at the level of the VCO 
Client application. 

Host System Equipment Requirements 

Following are the requirements for the host 
computer, adapter cards, peripherals, and system software 
20 components requisite to VMCS implementation, as already 
described. Each item is intended to represent an example 
component; many permutations of features and hardware 
configurations are acceptable for actual deployment, 
though the configuration outlined below is provided in 
25 specific terms to enhance the clarity of subsequent 
references. 

• IBM-compatible Personal computer 

A Personal Computer is the preferred host 
system. It should have a Pentium processor 
30 running at 120Mhz or faster, contain at least 

sixteen (16) megabytes of random access 
memory, and a minimum of 500 megabytes of 
backing store capacity. 
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32-Bit Multitasking Operating System 

The VMCS host: operating system should provide 
protected memory address space for each 
process, support multiple threads, and have a 
preemptive scheduler. 
Graphical User Interface 

A VMCS host operating system user interface 
should be event-driven, and provide a 
windowed graphical "object-desktop" 
environment where each visual component can 
be manipulated by 

drop/drag/cut/paste/properties operations . 
Audio and Video CODEC Devices 
Audiovisual encoding and decoding hardware 
may be integrated with other devices onto one 
or more adapter boards that plug into 
expansion slots in the computer. The CODEC 
devices for this implementation must encode 
audio and video inputs from a microphone and 
camera, respectively, to a multiplexed 
digital signal compliant with the H.221 frame 
structures. Decoding must proceed from this 
H.221 compatible signal to an analog audio 
output, and a VGA video signal for output to 
(for example) a video display terminal. 
Video Display Adapter with Overlay Controller 

A high-resolution video graphics adapter must 
be installed so as to work in conjunction 
with a video overlay device. This hardware 
configuration will support the station's 
principle visual graphics information output 
pathway by enabling the simultaneous display 
of bitmapped graphical and motion-video. This 
sub-system must permit motion-video display 
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in a windowed portion of the main screen, a 
region programmatically selected for that 
purpose. The overlay controller allows the 
display of motion-video over a region of the 
bitmapped display device by enabling the 
real-time overlay of NTSC video frames onto 
the identified region of the main display 
bitmap . 

Audio and Visual Peripheral Transducers 

These peripherals include input devices such 
as an NTSC camera to input motion-video, a 
microphone to input audio, and a 600 DPI 
color scanner to input high-resolution still 
images. Output devices include a 17" CRT 
display (1280 x 1024 resolution that can 
display 65,535 colors) for bitmapped and 
motion-video output, a loudspeaker for audio 
output , and a color laser printer for 
hardcopy photograph and document output. 
Audiovisual devices may plug into analog 
signal ports on adapter boards designed 
specifically for the purpose of PC bus 
interface, or into standard digital computer 
ports (according to their own unique 
interfacing requirements) . 
Media Access Control Device Drivers. 
Device drivers must be provided for the audio 
and video adapter boards (including the 
overlay controller) enabling the 
initialization, configuration, shutdown, and 
querying of each. System device drivers must 
be available to input scanner images, output 
printer images, and control system data 
ports, among other standard system services. 
Network Interface Unit (NIU) 
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A network interface unit roust provide the 
physical link to the network. It needs to 
support a minimum transfer rate of 128 kbit/s 
through a plesiochronous network (see 
U. Black, ATM, Foundation for Broadband 
Networks, Englewood Cliffs, New Jersey, 
Prentice Hall PTR, pp. 36-37, 1995) such as 
that provided by the Integrated Services 
Digital Network (ISDN) . In the case of a 
host PC, the physical network connection 
extends to an ISDN phone jack, from an 
adapter card plugged into one of the 
computer's expansion slots. A fully-digital 
ISDN modem device is usable for this purpose. 
Network Protocol Stack 
The network interface must provide 
programmable software control of the physical 
network service, and in the case of the 
recommended ISDN configuration, ISDN network 
protocol software must provide accessibility 
to one or more b- channels (for encoded 
audio/video data) and to a d-channel for the 
out-band signaling required for H.320 
protocol implementation. Data packets from 
the system must be directly accessible for 
synchronous transfer to and from the 
decoder/ encoder devices (audio and video 
CODECS) . 

ISDN Basic Rate Interface (BRI) 

For the preferred ISDN network interface, the 
ability to establish a connection supporting 
128 kbit/ sec is generally accepted as the 
absolute minimum bandwidth needed to support 
a primitive motion-video image (with a 
concurrent audio signal) across the ISDN. A 
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typical BRI installation is utilized as a 
2b+ld channel configuration. For most 
purposes, a triple-BRI, or composite line 
conf iguration (384 kbit/ sec) is preferable, 
5 as it is capable of producing an image closer 

in quality to that is generally considered 
acceptable in other video applications. 

System Development Requirements 

Developing a VMCS from preexisting hardware 
10 components is a combined system and application software 
development effort. Initial development of a VCO to 
control a set of devices is a significant undertaking 
that involves careful interface to device control 
software, and implementation of many of the specific 
15 protocols residing under the H.320 rubric. While 

implementation of the prototypical VCO kernel is non- 
trivial, diligence is repaid many times over in that 
nearly all of the kernel source code is propagated, in 
rote fashion, to create a new VCO that can readily 
20 support a new set of devices. The client application 
binaries are directly re-releasable — client programs 
are fully device-independent and run over any VCO built 
to specification. Requirements to implement a VCO are 
outlined as follows: 
25 • VMCS Disclosure provides the necessary 

description of a Virtual ized Multimedia 
Connection System to derive a design for an 
actual implementation. A complete set of the 
ITU-T recommendations referenced in ITU-T 
30 Recommendation H.320, are a necessary adjunct 

to the implementation and testing of fully 
compliant protocol implementations (see 
REFERENCES) . 
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• C++ software Development System or a 

functionally equivalent object-oriented 
development system must be used to create 
both the VCO (server) and client portions of 
5 the VMCS. Full implementation of the 

referenced AT&T C++ language must be 
supported. 

• Developer Toolkits provided by hardware and 
software OEM's, whose components are to be 

10 incorporated as VCO components, is essential 

to porting the device-independent VCO kernel 
to a new multimedia connectivity sub-system* 
Software tools to create the graphical user 
interface modules (such as exception handler 

15 message boxes and configuration displays) 

must also be available. 



Software Development Considerations 

To restate the purpose of VMCS server components: 
it is the primary directive of every VCO to bind, 

20 dynamically at run-time, a connectivity source to a set 
of transducers; and do so in such a way that the service 
provided to client applications serves as a mechanism to 
share spectral information between interconnected 
stations. In the use of it, no consideration is given to 

25 any intermediate data transmission methods employed. It 
is the responsibility of the VCO implementer, to ensure 
that sound and light directed to and from the remote 
station, are somehow seamlessly, automatically, and 
transparently transited over the void that may exist 

30 between data streams associated with the source of 
connectivity, and those associated with the local 
transducers. Most systems utilize an integrated 
audio/video hardware design to provide a direct analog 
signal link between these parts — consider those 
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manufacturers mentioned in the Background section — but 
this model is crippling to the station in its other 
purposes for reasons aforesaid. 

The operating system type specified for this 
5 system is characterized by the ability to spawn threads 
that run concurrently at specified priorities. They can 
be utilized to support transparent (to applications 
running in the foreground) real-time data streaming 
facilities. Data streams to/from connectivity sources 

10 can be attached to/ from transducers, so as to bridge any 
gap between discreet devices installed separately in the 
system; sharing data between separately installed devices 
requires read/write operations executed by the 
microprocessor (there is no direct analog signal 

15 connection between devices on different adapters) . With 
the specified operating system type, a station can take 
advantage of the multiprocessor personal computers that 
would support' the transfer of data at very high speeds 
(between devices in the system) , even at rates sufficient 

20 for normal system operation, while processing audio and 
video in real-time. 

Whatever mechanism is used, hardware or software, 
the VCO implementation must create the operational 
context in the system, dynamically when invoked, to move 

25 data between system components. It must do so in a way 
that is fully protected, secure, and unaffected by other 
system activities. The creation of the sub— system's 
operational context must be transparent to the client 
application, as must its destruction at session's end. 

30 VCO SOFTWARE IMPLEMENTATION 

A VCO is mostly comprised of software objects 
whose member function implementations are overridden by 
more derived versions of themselves that provide 
structured access to the services of installed adapter 
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devices* As the VCO architecture is a direct application 
of software object technology, to elucidate the details 
of its embodiment entails discussion of its components in 
terms of a class derivation hierarchy. Next follows 
5 examination of the VCO's class structure. 



VCO Class Derivation 

One VCO implementation encapsulates one specific 
sub-system configuration that exhibits a particular set 
of properties (capabilities) that defines its unique 

10 service profile — unique in the set of standardized VCO 
operations it can support, but no different from any 
other VCO in the way it presents them to client 
applications. Correspondingly, each VCO is no different 
from any other in the way it is implemented. In fact, 

is there are a number of implementation principles to 

consider prior to VCO design specification, thus speaking 
generally towards application of the concept... 

• More derived classes in the VCO are more 
device-dependent, ranging from the device- 

20 independent VDI classes, to the device- 

dependent class PDI. 

• Less derived classes in the VCO are less 
device-dependent, wherefore all VCOs contain 
the same device- independent kernel (that is 

25 comprised of class VDI and all those from 

which it is derived) . 

• More derived classes are more time critical, 
ranging from the VDI that responds to 
occurrences of events in OS-scheduled time 

30 slices, to the PDI that can queue events 

during interrupt service routines, invoked in 
real-time by device requests for interrupt. 

• Afore derived implementations (more device- 
independent default implementations) of VCO 



PCT/US97/15018 



- 101 - 

virtual members substituted with a more 
suitable implementation overriding them with 
one more device-specific (residing in a more 
derived class); that is, a default function 
is provided by the VDI, which the programmer 
can override in his particular implementation 
of the same feature. 

In most cases, jnore that 90% of the VCO 
source code is reused in the next VCO 
implementation without modification, due to 
the imposition of rigorous functional 
constraints (by the VCO architecture) on its 
class structure. 

A pure virtual member interface in the 
device- independent VDI, to more derived 
device control members in the device- 
dependent PDI, impose strict isolation of 
logical from physical operations. This 
isolation of logical operations from physical 
device operations, is realized by exploiting 
object-oriented software language constructs, 
integral to the language itself; structural 
integrity and layering of operations in the 
VCO is enforced at the most fundamental level 
of source code expression. The device control 
members used by the VDI (to lend physical 
device control to the implementation of its 
algorithms) are accessible directly in the 
same class, but the underlying device control 
mechanism is (for all intents and purposes) , 
in one more derived and not directly 
addressable. Resultantly, any changes to the 
way these more derived device control members 
are implemented, are beyond its discerning. 
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• Design-level isolation of logical and 

physical device control mechanisms in the VCO 
ar chitecture , are incorporated so as to 
intentionally expose a well-defined, readily 
5 exploitable "fissure" in its layering model, 

whereby the core technology is rendered 
amenable to specific extensions of concept. 
The implementations of certain system designs 
are significantly reduced in expense and 
io difficulty as a direct result of the well- 

defined logical-to-physical mounting 
mechanism. Some applications of concept 
advanced by its accessible mounting mechanism 
include: 

is • Rapid prototyping and redeployment for 

new sub-system configurations 

• Distributed VCO development by VDI and 
PDI development teams 

• Microcoded or embedded PDI 
2 o imp lement a t i ons 

• Distributed media control systems 

• Remote station control and diagnostics 

The class derivation diagram depicted in FIG. 6 
shows the classes that directly comprise the VCO, as well 

25 as adjunct classes (Notif ier and MCO) that are used to 
implement its feature set. Every component shown is used 
in every VCO implementation exactly as shown. Class VDI, 
being the Virtual Device Interface used by clients to 
access the VCO's encapsulated sub-system, is the only 

30 class, besides the public constructor and destructor in 
class VCO, that contains public member functions. The 
symbols used to describe the various relationships 
between classes are mostly proprietary to this 
disclosure, as no widely-used convention to graphically 
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express object-technology concepts has been adopted by a 
major standards organization. Symbolic conventions used 
here are shown in FIG. 1. 

Summary of VCO Class Derivation 

5 Each VCO is a composite derivation of the six 

classes: Terminal, Exception, Event, VDI, VL, PDI, and 
VCO. In the order of least to most derived, the 
derivation sequence for the VCO itself, proceeds as 
follows: 

10 • Class Terminal enables the VCO to send text 

messages to a set of character output 
devices, or receive text messages, that are 
subsequently interpreted as commands. Since 
the VCO terminal can be programmed to use the 

is VCO notification mechanism as a virtual 

output device, the class contains a pure 
virtual member used to direct text output to 
a Notifier Object configured for such 
purposes. This member is overridden by a 

20 supporting member function in the more 

derived class Event, and this override must 
be present for class terminal to compile. 
• Class Exception is derived from class 

Terminal, and is defined to contain member 

25 functions and data related to reporting fatal 

errors by responding in some pre-conf igured 
way. In the most primitive sense, the only 
service that class Exception must be able to 
access is some method to relay the fact that 

30 the exception occurred, and by inheriting 

members of class terminal, it can. Class 
Exception also has a virtual function used to 
shutdown the VCO when an exception occurs. An 
override in the VDI provides an 
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implementation that shuts down the VCO, as 
expected during fatal errors. 

Class Event is derived from class Exception, 
and is defined to contain the VCO event 
manager, which in turn manages the 
notification mechanism. It maintains a linked 
object list of Notifier Objects which are 
themselves each individually derived from the 
NOTIFIER data structure. Every Notifier 
Object is a protected class that is created 
by class Event, and is a friend to it. Class 
Event, but no other, can create, delete, or 
access class Notifier members directly except 
members of class Event, thus the Notifier 
Objects are essentially creatures of it. The 
event handler is the VCO's "proxy" to the 
linked list of Notifier Objects. Class VDI is 
a protected derivation of class Event. It is 
defined to contain a large set of members 
that comprise the VCO Software Control 
Interface, and a number of device- independent 
protocol support procedures. Inheriting the 
services of classes Terminal, Exception, and 
Event, it is capable of presenting the entire 
VMCS connectivity services through the member 
functions of a single binary software object; 
that is, one instantiated upon construction 
of a class derived from it. 
Class VI. is derived from class VDI, and 
provides a location for an implementation- 
dependent set of routines to map physical 
device control operations and responses 
to/ from the logical representation 
manipulated by members in the VDI. Most of 
its members are private to it, and narrowly 
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focused in scope. Entry points to translation 
and mapping services are made public to more 
derived classes that wish to utilize them* 
Class PDX is derived from VT,, and contains 
within it, private definitions and 
implementations of member functions that 
override the pure virtual device control 
members used in the VDI to invoke the 
services of physical devices in the 
encapsulated multimedia connectivity sub- 
system* The implementation of the pure 
virtual overrides utilize members in the VL 
to translate and map the structure of 
arguments and input/ output data syntax to 
that expected by the VDI implementations. The 
POI contains mechanisms to access the VCO 
Media Control Object Device Control Mechanism 
(Media Control Objects) . This mechanism 
relies upon the maintenance of a linked 
object list of instances of class MCO 
maintained much like the linked list of 
Notifier Objects in class Event. Class MCO is 
derived from an MCOPARAM data structure that 
serves as a general purpose repository for 
device control information as associated to a 
particular signal from a particular device. 
As with the administration of Notifier 
Objects, instances of class MCO are directly 
accessible only by the PDI; only the PDI may 
directly examine, modify, and invoke their 
members. The design of the VMCS is to promote 
its utilization in a variety of operating 
environments that include distributed 
systems, remote access across a network 
connection, and text command (teletype) 
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interface via dumb terminal. Members of class 
MCO are accessible to underlying Media Access 
Control software, and MCO implementations 
make calls to the same to invoke device 

5 services. 

• Class VCO is derived from class PDI, and 

functions as the capstone for the VCO class 
structure. The only members it inherits from 
its parent classes are the public members 

o that comprise the SCI in the VDI. Its 

constructor and destructor call those of its 
parent classes, thus it invokes those of the 
VDI to create and destroy the VCO session. 
Class VCO contains all additional 

5 implementation-specific entry points (object 

members) that are presented to client 
applications, including extensions to the 
VMCS that are not directly related to 
controlling the connectivity session. All 

o client applications proceed with the 

expectation that the invocation of VCO 
services will always be accomplished using a 
pointer or reference to class "VCO" . 

Class Components 

5 Next follows detailed descriptions of the 

operations that must be implemented by each class 
comprising the VCO. 

Class Terminal 

Provides full implementation of the VCO terminal 
services by maintaining a list of output devices for the 
output terminal, and writing all text message sent to the 
terminal output port to every device on this list. Text 
messages sent to the terminal input port are assumed to 
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be VCO text commands* They are parsed into tokens, 
decoded, and executed as SCI commands. The sub-components 
residing in this class are listed below, with an 
accounting of the specific operations for which they must 
5 provide support. 

• Terminal Stream I/O Device Controller 
Operations supported by this sub-component 
must include the following: 

• Add output device to list 

10 • Remove output device from list 

• Write text message to output device 

• Text Command Decoder 

Operations supported by this sub-component 
must include the following: 
15 ♦ Parse text command message to command 

token list 

• Verify command syntax 

• Execute command token list as SCI 
command 

20 • Text Command Encoder 

Operations supported by this sub-component 
must include the following: 

• Verify command syntax 

• Translate SCI call to text command 
25 message 

• Linked Terminal Stream I/O Device List 
The list itself is implemented as a linked 
object list, where each object contains the 
member functions and member data necessary to 

30 transmit data to the file, device, signal, or 

data port referenced by it. 
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Class Exception 

Provides full implementation of the VCO exception 
handling operations that include reporting the occurrence 
of the exception, and subsequently shutting the VCO down. 
5 Additional features of this component include the 

maintenance of an enable /disable flag that is tested by 
every public member function upon entry into the VCO; a 
disabled VCO must reject any call into it, and return the 
"Disabled" result code to the caller. There are a number 
10 of flags that can be used to configure the exact modality 
used by the exception handler to respond to exceptions, 
and each modality must be supported by the exception 
handler implementation, in accordance with the 
definitions shown in FIG. 6A. The sub-components residing 
15 in this class are listed below, with an accounting of the 
specific operations for which they must provide support. 
• Exception Handler 

Operations supported by this sub-component 
must include the following: 
20 • Process VCO exceptions accordingly (see 

FIG. 19) 

• Provide for capability to display debug 
information message box 

• Display "user" information message box 
25 • Send text information message to 

terminal 

• Trigger Notif ier on exception 

• Trigger VCO disabler mechanism on 
exception 

30 • Disabler Mechanism 

Operations supported by this sub-component 
must include the following: 

• Maintain VCO enabled/disabled flag 

• Provide for query of enabled/ disabled 
35 flag (see FIG. 19) 
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• Invoke system shutdown utilizing virtual 
override in VDI 

Class Event 

Provides full implementation of the VCO event 
5 management operations. A list of Notifier Objects is 
maintained, and a mechanism to trigger them is contained 
in this sub-component. The VCO event queuing and 
dispatching mechanisms are located in this component, 
though critical section handling may be located in the VL 

io to make use of special operating system support for 
semaphores and thread blocking features. There are 
thirty-two (32) distinct events that have been 
standardized for VMCS use. FIG. 6C shows the symbolic 
identifiers for these events, and provides concise 

15 definitions for each. The physical source of the event is 
labeled as either hardware (HW) or software (SW) , and 
accompanied by a code that goes on to further clarify the 
specific system component from which the event is likely 
to (though not necessarily) emanate. 

20 VCO developers creating a VCO to work with a new 

device set, must identify the most reliable source for 
VCO events originating in hardware, and then map vendor- 
specific representations of the event to those virtual, 
standardized, and described in FIG. 6B. Third-party 

25 device drivers in the MAC layer may not provide access to 
events identical in meaning or context to those cataloged 
by the VCO; some interpolated or emulated derivation 
(from events closely related) may be necessary for a 
compliant indication of the standardized occurrence, and 

30 any member functions created to approximate the 

representation of one such only marginally identifiable, 
should reside in the VL layer for invocation by members 
in the PDI. 

The event manager is also responsible for managing 
35 the flow of trace information to its terminal output 
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port. The sources from which trace information emanates, 
can be programmed in an additive fashion, by specifying a 
trace output profile. There are a number of flags, 
applied to express this profile as a logical combination 
5 of trace output source locations within the VCO's works, 
and each modality must be supported by the event manager 
implementation, in accordance with the definitions shown 
in FIG. 6B. The sub-components residing in this class are 
listed below, with an accounting of the specific 
10 operations for which they must provide support. 

• Notifier Object List Manager 
Operations supported by this sub-component 
must include the following: 

• Create and add new Notifier Object to 
15 linked Notifier Object List 

• Remove Notifier Object from list and 
delete 

• Set Notifier Object triggers 

• Get Notifier Object data 

20 • Lock Notifier Object List against 

add/remove operations while triggering 

• % Unlock Notifier Object List to allow 

add / remove oper a t i ons 

• Notifier Object List 

25 The list itself is implemented as a linked 

object list, where each object contains the 
member functions and member data necessary to 
configure the Notifier Object's triggering 
profile, as well as to actually trigger it to 

30 deliver notification to its associated 

Notification Receiver Object. 

• Notification Triggering Mechanism 
Operations supported by this sub-component 
must include the following: 
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• Trigger Notif ier Objects in Notifier 
Object List (see FIG. 10) 

Event Dispatcher 

Operations supported by this sub-component 
must include the following: 

Dispatch event (see FIG. 11) 
Start dispatcher 
Stop dispatcher 
Set dispatcher rate 
10 • Configure dispatcher 

• Event Queue 

Operations supported by this sub-component 
must include the following: 

• Add event to queue (see FIG. 11) 

15 • Remote event from queue (see FIG. 11) 

• Flush queue 
Class Notif ier 

Provides full implementation of the VCO Notifier 
Object (NO) . Each NO is a self-contained reporting 

20 mechanism called a thunk. This thunk must be created by 
any class that wishes to be informed of the occurrence of 
a VCO event. The thunk provides a globally defined entry 
point to the address space of the instantiated class 
object that is to receive notifications, and the thunk 

25 retains knowledge of the exact class name and specific 
class member designated to receive notifications (from 
the NO residing in the VCO itself) . The NO stores a 
pointer to this global entry point (the thunk) , a pointer 
to the Notification Receiver Object (NRO) , and a pointer 

30 to the NRO's Notification Receiver Member (NRH) that is 
the ultimate destination for delivery of notification. 
The NOTIFIER data structure from which the Notifier 
Object is derived, contains all of this information, the 
achieved objective in its tracking to enable an immediate 

35 conveyance of a unit of system event information (a 
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standard VCO event) directly from a driver- level 
component to the application, as soon as there exists an 
opportunity for the operating system to run the 
interested application. With regards to VMCS 
5 implementations and their notification mechanism, system 
designers should first reflect upon the following: 

• Notifications are designed specifically to 
operate like system interrupts, independent 
of user interface event queues. Like 

10 interrupts, they require service only in 

response to very specific occurrences to 
which they are programmed to respond — 
service routines do not have to test for a 
wide range of possible triggering events, but 

15 can act directly with simple, well-defined 

operations. 

• Notifications from the VCO are virtually 
unaffected by user- interface operations, and 
events are never lost to "queue-full" 

20 conditions. They are fast, configurable, 

flexible, and offer a measurably more 
reliable feedback mechanism than the typical 
GUI event delivery mechanisms, but 
expectantly can interrupt drawing operations 

25 in progress. Drawing operations, to display 

information delivered by a Not if ier Object, 
are best executed from a specific painting 
routine, whose invocation is governed by the 
receipt of paint messages from the GUI — 

30 painting messages and graphics to the display 

with each notification can prevent the GUI 
from processing messages in its own event 
queue. 

• Consistent with the previous point, NRMs 

35 should be constructed as high-level interrupt 
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service routines that insert an event into 
the application's event queue (GUI event 
stream) , or spawn a new thread to exact some 
effect on the system, and return immediately. 
5 To delay processing on a notification thread 

could delay notification to other VMCS 
objects (if a single thread is used by the 
triggering mechanism to trigger all NOs) • 
Beyond delay, none of the usual problems 
io associated with delayed interrupt processing 

occur since the VCO queue retains all events 
till processing is resumed; no information is 
ever lost. Further, VCO events are but 
shadows of real-time events that will have 
15 long since been serviced in real-time, 

according to the methods implemented by 
driver-level vendor spec if ic components. 
However, correct designs for systems will 
service all outstanding event notifications 
20 and return long before the VCO dispatcher is 

ready to remove another event from its queue. 
The constructors of Notifier Objects add them to a 
linked object list upon construction, and remove them 
from the list upon destruction; their structured 
25 integration into a linked storage format is managed 

automatically. An accounting of the specific operations 
for which this class must provide support are listed 
below: 

• Notifier Object Operations 
30 Operations supported by this sub-component 

must include the following: 

• Find Notifier Objects to trigger in 
linked object list (see FIG. 10) 

• Trigger individual Notifier Object in 
35 list (see FIG. 10) 
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• Set Triggers 

• Get: Statistics 

• Reset Statistics 

Class VDX 

5 Provides full implementation of the VCO Software 

Control Interface (SCI) , along with a number of private 
support functions. Any device- independent routine 
necessary to VCO implementation resides in this class. 
The header file VDI.H (see Appendix) contains all of the 
10 constants , enumerations , and data structures used by both 
server and client portions of the VMCS. Following those 
definitions, is that of the SCI. These member functions 
are the virtualized definition of the VMCS control 
mechanism from the client application's perspective, and 
15 are the only public members of the VCO; notably excepted 
is the VCO constructor and destructor in class VCO. Not 
shown in VDI.H are the device- independent call and 
protocol management routines that provide support for the 
VCO connectivity sessions* They are implementations of 
20 various Recommendation H.320 protocols. The session- 
related sub-components residing in this class are listed 
below, with an accounting of the specific operations for 
which they must provide support. 

• Network Session Operations 
25 Operations supported in this group of member 

functions have public entry points that are 
represented in the SCI (see Section entitled 
VDI Header Pile in Appendix). They are noted 
here to reference figures that detail their 
30 flow control pathways. The Network Session 

operations must include the following: 

• Construct VCO (see FIG. 24) 

• Destruct VCO (see FIG. 24) 

• Open VCO (see FIG. 25) 




• Close VCO (see FIG. 26) 

• Make call to remote station (see FIG. 
27) 

• Execute multipoint call operation (see 
FIG. 28) 

• Hang-up call or line (see FIG. 29) 
Media Control Object Device Control 
Operations 

Operations supported in this group of member 
functions are accessed by the public 
audiovisual /data signal switching control 
members in the SCI (see section entitled VDI 
Header File in Appendix) . A query flag passed 
during a call to this member function 
determines whether or not a request for 
service or capability query is invoked. 
Operations supporting the service and query 
requests must include the following: 
Media control operation service request (see 
FIG. 20) 

• Media control operation query request . 
(see FIG. 21) 

Device- independent Call Controller 
Operations supported in this group of member 
functions respond to line state events from 
the Device Event Processor, to manage the 
connectivity session. Call control related 
members must include the following: 

• Enter call controller and process line 
event (see FIG. 14) 

• Execute procedure to handle incoming 
line disconnected (see FIG. 15) 

• Execute procedure to handle incoming 
line dialed (see FIG. 16) 
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• Execute procedure to handle incoming 
line ring (see FIG. 17) 

• Execute procedure to handle incoming 
line ringback (see FIG. 16) 

• Execute procedure to handle incoming 
line connected (see FIG. 16) 

• Execute procedure to handle incoming 
line busy (see FIG. 16) 

• Reset call data to default states (see 
FIG. 18) 

• Restore default connected device modes 
(see FIG. 18) 

• Set connected device modes (see FIG. 18) 
Device-independent Capability Exchanger 
Operations supported in this group of member 
functions contribute to implementing an 
algorithm that employs an H.221 mode- 
capability cross-reference table to determine 
if the connection between logical and remote 
stations can support a given H.221 device 
mode; that is, it compares the capability 
associated with the mode to the logical 
intersection of the capabilities of the local 
and remote stations. Capability exchange 
operations are internal to the VCO, and must 
include the following: 

• Accessibility to an H.221 mode- 
capability cross-reference table 

• Determine if connection supports mode 
(see FIG. 12) 

• Determine if capability is associated 
with mode (see FIG. 13) 

• Determine if local station supports 
capability (see FIG. 13) 
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• Determine if remote station supports 
capability (see FIG, 13) 

• Device-independent Device Event Processor 
A member function in the VDI is a 

5 Notification Receiver Member that receives 

notifications of device events from a 
Notifier Object created by the VCO at the 
time of its construction. Any events in FIG. 
6C, whose source is identified as hardware, 

io is considered a device event, and the Device 

Event Processor responds to them to maintain 
the current connectivity session. Device 
events are processed according to a specific 
algorithm that routes them through 

15 appropriate control flows depending on their 

particular category (see FIG. 23) . 

• Pure Virtual Device Control Members 

There are no implementations of these members 
in class VDI; only the member declarations 

20 are present (see section entitled VDI Header 

File in Appendix) . These members are used 
extensively by implementations of other VDI 
members to provide the device interface for 
all operations that access vendor-specific 

25 driver components and their underlying 

physical devices. 



Class VL 

Provides full implementation of any members 
necessary to convert, translate, map, or interpret 
30 operations and data formats between conventions used by 
logical controls in the VDI, and Physical Device 
Interfaces accessed by the PDI (MAC layer components) . 
This class may vary greatly in the number of member 
functions it must contain for a particular VCO 
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implementation. The header file PDI.H (see section 
entitled Physical Device Interface File in Appendix) 
contains a definition of an empty class VL to show its 
role in the derivation of the VCO. Virtualization 
5 operations are unlikely to be device-independent, however 
the categories of operations they commonly must implement 
are preserved across most VCO implementations, and are as 
follows: 

• Virtualization Operations 
10 • Software Component Load/ Initialization 

Software Component Unload/ Shutdown 
Configuration Information Access 
Data Exchange Syntax Mapping /Emulation 
Call Event Mapping/ Emulation 
is • System Information Mapping/ Emulation 

Capability Exchange Mapping/Emulation 
System Exception Mapping/ Emulation 
Media Access Control Mapping/ Emulation 
Protocol Mode Mapping/Emulation 



20 Class PDZ 

Provides full implementation of the VCO device 
control interface, including a number of operations to 
interface operating system services. A pure virtual 
override member must be implemented to support the 

25 operations defined for the pure virtual device control 
members defined in the VDI (see section entitled VDI 
Header File in Appendix) . The header file PDI.H contains 
the definition of class PDI (see Appendix) and shows its 
role in the derivation of the VCO. Implementations in 

30 class PDI have no restrictions on the way they interface 
devices. Media Control Objects (instances of class MCO) , 
are the preferred mechanism. At the time the VCO is 
opened, when its devices are initialized, the PDI creates 
an array of Media Control Objects that describes the 
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available, and expected-to-be-available, audiovisual/data 
signal types • These Media Control Objects contain the 
member functions and data structures needed to control 
the device that is the source of, or destination for, the 
5 signal they represent to the VCO. The next section 
entitled MCO Device Control Mechanism goes on with a 
further discussion of the Media Control Object Device 
Control Mechanism. The sub-components residing in this 
class are listed below, with an accounting of the 
io operations for which they must provide support. 

• Pure Virtual Device Control Member Override 
Operations 

Operations supported by this group of members 
are best described by the descriptions of the 

15 pure virtual member functions defined in 

class VDI (see "Class VDI") . The pure virtual 
overrides residing in class PDI are 
implementations of the pure virtual device 
control members declared in class VDI (see 

20 section entitled VDI Header File in 

Appendix) . 

• Device Capability List (H.221 Capability BAS 
Codes ) 

A list of device capabilities is stored in 

25 the VDI (see section entitled Bit-Rate 

Allocation Signal Header File in Appendix) , 
but must be maintained by the PDI. A local 
capability list in the VL is copied into the 
VCOPARAM structure in the VDI during VCO 
30 construction. Incoming capabilities from the 

remote station are written to the remote 
capabilities field of the VCOPARAM structure, 
by callback members in class PDI, and are 
called by the connectivity protocol stack 
35 when capabilities are transmitted from the 
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remote station. VCO device capabilities are 
represented as device- independent constants, 
so there may be a necessary mapping operation 
from the BAS code (or proprietary) 
representations used by the connectivity 
protocol stack to /from those defined for the 
VMCS. 

Device Modes List (H.221 Device Mode BAS 
Codes) 

A list of all H.221 device modes is kept in 
the PDI as a reference. This list is used to 
determine if a mode is standard, non- 
standard, of a given type, or invalid. 
Device Event Linkages to Queue 
In order for the PDI to be informed that 
device events have occurred, a number of 
callback functions are declared in this 
class. Such callbacks can typically be 
classified and implemented as follows: 

• Connectivity Protocol Stack Callback 
Members are called by routines in the 
software modules that implement the 
connectivity protocol. In connectivity 
protocol stacks encapsulated by the VCO, 
the callbacks come from the OS I 
transport layer (or its equivalent) . 
They call the VCO to report any changes 
in line states, the arrival of BAS codes 
from the remote station, and for a wide 
variety of status-related events, as 
defined in FIG. 6C. 

• Media Access Control Callback Members 
are called by routines in the device 
drivers that comprise the MAC layer. 
They call the VCO to report changes in 
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device states, results of device 
operations, and a vide variety of 
status-related events, as defined in 
FIG. 6C. 

5 Upon receiving an event from any callback 

function, the vendor-specific event is mapped or 
translated to one of the standard VCO events, and added 
to the VCO event queue* Routines in class VL may be 
called for this purpose. 

o class VCO 

There are no specific components to implement in 
this class. Extensions to the VCO feature set, beyond 
those related to control of the encapsulated sub-system, 
should be added as members to this class; it is the place 
5 specifically intended for such enhancements. The header 
file VCO.H contains the definition of class VCO (see 
section entitled General VMCS Header File in Appendix) 
and shows its role in the derivation of the VCO. All 
client applications must include this file in order to 
o access the services of the VCO itself. Class VCO is the 
class that is constructed by the client, and it presents 
to this client a number of public member functions 
described as follows: 

— • Public VCO Members Available to Client 

5 • VCO is the constructor of the VCO, and 

invokes the constructors of all less 
derived classes when invoked. 

• ~VC0 is the destructor of the VCO, and 
invokes the destructors of all less 

0 derived classes when invoked. 

• inherited Public Members from the SCI 
are all presented to the client 
application as members of class VCO. 
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• Implementation-dependent Extensions can 
declare public member functions in class 
VCO that offer their services to the 
client application seamlessly with other 
5 vco functions. 

HCO DEVICE CQNTRQfr MECHANISM 

The device control diagram depicted in FIG. 7 
shows how the VCO is able to reference the devices in its 
encapsulated sub-system as configurable representations 

10 of the data streams that they generate, process , or 

redirect. Client calls to the SCI are shown to invoke SCI 
members that, according to their specified function, rely 
on calls to pure virtual device control members for their 
implementation, thus not all SCI members are included in 

15 the diagram. The sixteen default Media Control Objects 
are arranged in the drawing to clearly demark the low- 
level, vendor-specific component to which they 
correspond, and manipulate when affected by PDI calls to 
their members. Vendor-specific MAC components should be 

20 considered bi-directional — they support control 

pathways and data streams to and from a media control 
sub-system — and the different types of transducers 
required for each direction are clearly evident. 
Concordant ly one finds the "audio" objects reference a 

25 MAC component supporting audio input and output, and to 
that single MAC component is connected both microphone 
and speaker. PDI calls made directly to the connectivity 
protocol stack and MAC components are not shown 
explicitly in the drawing, as the exact structure of 

30 their interactions are left to the implementer ' s 
discretion. 
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Summary of Device Control Mechanism 

Client calls to the SCI invoke members that often 
require the support of the encapsulated multimedia 
connectivity sub-system in their implementations. The 
5 implementations of SCI members, such as "Open" and 
"Call", make requests for physical device control 
services by utilizing at least one of the pure virtual 
device control member functions declared in class VDI; 
these members are private and entirely separate from the 

10 public SCI members offered to clients. The PDI contains 
overrides for these pure virtual device control members. 
These overrides invoke the appropriate device operations 
by making calls directly to the connectivity protocol 
stack or MAC layer components, as is appropriate to the 

15 desired device control operation. Implementations of the 
pure virtual device control overrides must perform any 
and all interface to vendor-specific hardware and 
software components necessary to fulfill the specified 
expectation of the pure virtual device control member in 

20 the SCI. 

If the particular SCI member, called by a client, 
is MediaControl, the method of interface to the physical 
device is different from that used for call and protocol 
operations; its purpose is to switch or configure the 

25 audio, video, image, or data signals represented as 

virtualized system objects, or Media Control Objects. In 
this case, the pure virtual override for MediaControl, 
implemented in the PDI, then manipulates the members of 
Media Control Objects that have been created to represent 

30 the various available signal types. Depending upon the 
exact nature of the request, audio, video, image, and 
data signals are combined, redirected, displayed, or 
routed to local devices or the remote station. The Media 
Control Objects can also be used to set various modes 

35 (associated with the signals) by directly controlling the 



WO 98/09213 



PCT/US97/15018 



- 124 - 

device associated with it. The operation of the Media 
Control Object device control system is detailed as 
follows: 

• Primarily there exist sixteen default Media 
Control Objects, as shown on the right side 
of FIG. 7. 

• There is an input and output object to/ from 
the remote station for each signal type (see 
FIG. 7A) , for a total of eight objects 
representing information shared between the 
local station and the remote station. 

• There is an input and output object to/ from a 
local device for each signal type (see FIG. 
7A) , for a total of eight objects 
representing information shared between the 
local station and its local environment. 

• The objects are only created when the signal 
they represent is within the capabilities of 
the system to support. They are only enabled 
when the signal they represent is actually 
available for access. 

• Any number of Media Control Objects can be 
created in the VCO to control more devices 
and data channels, as determined by their 
detected system device availability by the 
VCO. 

• Each Media Control Object, representing a 
specific signal type and direction, can be 
attached, or "plugged into" another Media 
Control Object that is compatible in both 
signal type and direction; For example, an 
audio source from a local device (microphone) 
can be attached to an audio output to a 
remote station, or a video input from a 
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remote station can be attached to an output 
to a local device (video display) 

• Each Media Control Object, regardless of 
signal type, contains a data structure that 

5 reflects the various states and modalities of 

the signal. Member functions for each Media 
Control Object, allow them to be manipulated 
as independent, uni-directional channels. 

• Certain Media Control Objects can be combined 
10 into composite media control objects that 

describe a complex signal type, such as 
multiplexed audio/ video information. The 
objects can also be combined with objects 
that subject them to a specific transform, or 
15 split/join configuration. 

• Setting the parameters of a source/ input 
object invokes a sub- system (driver- level) 
attempt to change the settings of the source 
device or station, whereas setting the 

20 parameters of a destination/ output object 

attempts to change the settings of the 
destination device or station. 



Audiovisual /Data Signal Switching Mechanism 

Device control operations are made directly 
25 available to VCO Client applications through the 

implementation of the MediaControl SCI member function, 
along with some related members that assist in the 
manipulations of these objects. The SCX members map to 
essentially identical pure virtual device control members 
30 implemented in the PDI. The switching of signals and 
device modalities generally takes place by selecting 
constants from various enumerated categories (see section 
entitled VDI Header File in Appendix) , and presenting 
them to the VCO with the MediaControl member. The format 
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of the arguments is constructed so that the specified 
operation applies to the currently assigned default Media 
Control Object for the specified Media Control Object 
type (see FIG. 7 A) . For example, a command to mute the 
5 input microphone would likely reference AudioSrc as the 
Media Control Object type. Handles are used to assign 
various non-default Media Control Objects as the default 
(one of the sixteen) for a given type. The continuous 
linear enumeration of all possible constant arguments 

10 used for MediaControl function calls give each setting a 
unique numerical identifier, and thus each can be 
associated with a unique string token. The argument 
formats for all of the MediaControl calls are detailed in 
the source code section (see section entitled VDI Header 

15 File in Appendix) . 

Media Control Object Physical Structure 

Each Media Control Object is a class object 
privately derived from an MCOPARAM (see section entitled 
VDI Header File in Appendix) structure. Regardless of the 

20 signal type (audio/ video/ image/data) represented by the 
Media Control Object, the MCOPARAM structure contains 
sub-records for all signal types. The programmer need 
only attend to the relevant section for the signal type 
for that object. There are a number of requirements as to 

25 the structure of the Media Control Objects physical 

structure, with regards to the specific details of its 
implementation. 

• All member functions and member data in the 
Media Control Object, are protected, and can 

30 only be accessed by the PDI. 

• Class PDI is a friend to all instances of 
class MCO. 
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• Class VDI cannot: access any HCOs directly, 
except through specific members that are 
implemented by class PDI. 

- • All MCO members presented to the PDI, should 
5 be simple, device* independent operations to 

manipulate the settings and operations 
precisely outlined by the audio, video, 
image, and data records contained in the 
MCOPARAM data structure, 

10 • Each MCO should be fully cognizant of its 

signal type and signal direction, and 
prohibit operations that are inconsistent 
with its fundamentally characteristic 
properties, i.e. cannot attach audio output 

is to a video display. 

• The handle of a new MCO must be added to the 
VDI tables in DEVI CEPARAM when that MCO is 
created, and removed when deleted, such that 
the client always has a clear picture of 

20 available system resources. 

• Events must be queued for each and every MCO 
operation executed. 

• Regardless of the complexity of underlying 
system components that must be initialized, 

25 addressed, or monitored to implement Media 

Control Object operations, it is critical 
that the designer reduce the invocation of 
such processes to simple operations described 
by the Media Control Object settings. 



. 30 MCO Interface to the Media Access Control Layer 

Each MCO controls the device underlying the 
signal it represents oy making requests to the Media 
Access Control layer components that drive them. The PDI 
pure virtual override DevMediaControl presents settings 
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to the Media Control Objects, and the Media Control 
Objects then go on to map the setting to a physical 
device control operation. FIG. 22 shows the control flow 
for device control operations that are presented to MCI 
5 drivers that comprise the MAC layer* This diagram has 
greatly simplified the pathway from the VDI to the MCI 
driver , eliminating most of the interactions with the 
Media Control Object. In short, the PDI prepares a Media 
Control Request Record, and presents it to the 

10 appropriate Media Control Object so that the object can 
fill in its fields, and present it to a corresponding MCI 
driver (see FIG. 22) . Note that a device control 
operation initiated by the local station can result in 
the station assuming a new H.221 device mode, which is 

is then transmitted to the remote station (if currently 
connected) for station synchronization, referred to as 
the "establishment of common modes 11 by Recommendation 
H.320. Finally, an event is added to the VCO event queue 
describing the new Media Control Object setting that has 

20 taken place. 

STATION ATTACHMENT MECHANISM 

There are a number of considerations with regards 
to the system components that must be created to support 
the "attachment" between two interconnected VMCS 

25 stations. A pathway must be established between the two 
stations such that they can share text string commands 
streams. Once this pathway is available, the two stations 
must come to a mutual understanding how they will 
interact; that is, which station is the master, and which 

30 is the slave. 

Beyond the standard attachment mechanism 
described, a third station can control any one of a 
number of stations that are themselves interconnected in 
a conference. In this modality, a "third party" 
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controller, or "remote operator" can intervene in 
conference already in progress to assist, diagnose, or 
monitor one of the conferees. The details of designs that 
would accomplish this task are supportable by the VMCS, 
5 but beyond the scope of this disclosure* Below follows a 
description of the details for the VCO components used to 
implement the remote station attachment mechanism. 

Command Stream 

From the perspective of one end of the attached 

10 station pair, the command stream is bi-directional — to 
and from the remote station. A Media Control Object 
supporting text data output to the remote station, and 
another Media Control Object supporting text data input 
from the remote station, are created to encapsulate the 

15 data pathways. Since mostly text message data will be 
exchanged, the pathway need only support low bandwidth 
(less than 16 kbit/s) on an occasional (asynchronous) 
basis. Data can be transported out -band on a separate 
channel (such as an ISDN D-Channel) or in-band, perhaps 

20 multiplexed with video data. The data transport mechanism 
for message data can also be accomplished through a 
tertiary source using an entirely separate connection 
from that used for primary communication. All messages to 
the remote station are written to the Media Control 

25 Object encapsulating the pathway to the remote station, 
while messages arriving from the remote station generate 
events as they are received by the Media Control Object 
encapsulating the pathway from the remote station. 

Event Encoder 

30 This component converts binary event records added 

to the VCO event queue to a text event message 
representation, and then sends it to the remote station. 
A definition of the binary event record is provided (see 
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section entitled VDI Header File in Appendix) , however 
the exact text event message format is left to the system 
designer* Suffice it to say that the text message format 
used should be entirely universal to allow all VMCS 
5 implementation platforms to engage in "attachment". 

String tables in the Linguistic Controller areas of the 
VCO are used to convert the enumerated arguments to 
string tokens , whenever possible, while purely numerical 
arguments (such as parameters) are converted to ASCII 
10 hexadecimal strings. Each event message must minimally 
include the following information: 

• Event ident if ier 

• 3 2 -Bit parameter 1 

• 3 2 -Bit parameter 2 

15 • Source station identifier 

The event encoder is usually only accessed when 
the VCO is attached to a remote station. While the VCO is 
attached, the encoder is invoked by the VCO gueuing- 
mechanism each time an event is queued. The encoding 

20 takes place using a separate thread of execution to avoid 
interference with device timing. 



Event Decoder 

This component converts text event messages 
received from the remote station and converts them to 

25 binary event records that are then added to the local 
VCO's event queue. This process is the inverse of the 
encoding process, and its success depends upon the 
consistency of the text event message format selected. 
The source station identifier tells the receiving VCO 

30 where the event came from, and the string tables in the 
Linguistic Controller are used here to derive a numeric 
representation by comparison of the string token keywords 
to their relative position in the tables, and derive a 
string index when the token is identified. The event 
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decoding -takes place using a separate thread of execution 
dedicated to fielding incoming command and event 
messages. 

Command Encoder 

5 This component converts SCI calls to a text 

command message representation, and then sends them to 
the remote station . As with the event encoder, the exact 
text command message format is left to the system 
designer, and correspondingly, it should be entirely 

10 universal for reasons said. String tables in the 

Linguistic Controller areas of the VCO are used to create 
text command messages whose format is variable depending 
on the SCI command encoded. The command encoding takes 
place using a separate thread of execution dedicated to 

15 fielding incoming command and event messages. 

Command Decoder 

This component redirects the text command portion 
of the shared messages to the local VCO terminal input 
port, where they are interpreted, and then used to 

20 generate calls to the local VCO's SCI, just as if they 
had been input from a local user at a terminal keyboard. 
This process is the inverse of the encoding process, and 
its success depends upon the consistency of the text 
command message format selected. The event decoding takes 

25 place using a separate thread of execution dedicated to 
fielding incoming command and event messages. 

Determining Capabilities 

Each VCO has associated with it independent 
parameter blocks for remote control parameters and remote 
30 monitoring parameters. There are separate parameter 

blocks each containing flags that indicate their current 
operating modes, and operating capabilities with regards 
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to attachment. The control and monitoring capabilities 
are stored as nonstandard capabilities in the local 
capabilities lists, and each station will know those of 
the other at the time of connection. Once attachment has 
5 been established, it is the station that first requests a 
particular control or monitoring "context" that will able 
to assume that role. When a role is assumed, flags in the 
associated parameter blocks mark the state, and prohibit 
any further context changes till the stations are 
10 detached, disconnected , or the change is initiated by the 
"controlling" or "monitoring" station. 

Remote Monitoring 

As a subset of a full remote control context , 
monitoring of a remote station requires only that the 

is "monitor" station receives a stream of the events queued 
by the "monitored" VCO. Upon connection, both stations 
are monitoring their own locally queued events; they are 
operating under fit local monitoring context. If one 
station permits (indicates it is capable of) being 

20 monitored, the other can change its monitoring context, 
by setting its monitor mode flags to include the remote 
stations events , and therefore add the events from the 
other station to its own event queue, in addition to 
continuing to monitor its own event stream concurrently. 

25 Alternately, it can monitor only those events of the 

other station, or monitor any one of a group of stations 
in a conference, as they come into focus (though a 
virtual attachment must be established with each 
individual station prior) . Monitoring can occur bi- 

30 directionally at the same time; two stations may monitor 
each other concurrently. 
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Remote control 

The assertion of control by one station, over 
another, proceeds similarly to the establishment of a 
monitoring context. In doing so, one station's 
s capabilities indicate it will assume a slave operating 
context, while the other will be the master. Upon 
connection, both stations are controlling their own 
systems; they are operating under a peer control context, 
and have no ability to control the other. The master VCO 

io initiates the transaction to request operational control 
of the other, and if consent is given by the other, it 
assumes the role of master, the other as its slave. The 
slave VCO now reacts to commands sent by the master, just 
as if the commands had been issued by its local client 

is application. For remote control to occur, the master must 
also monitor the event stream of the remote VCO. With the 
ability to transparently send commands to a slave 
station, and transparently receive events from the 
station in response to those operations, the VCO that 

20 assumes the master control context becomes a fully 
operational virtualized representation of the slave 
station. And client applications that run on the master 
VCO are (practically speaking) virtual clients of the 
slave VCO. 

25 MULTIPOINT CALLS 

A number of recommendations serve to define 
standard designs, protocols, and terms used for 
audiovisual connectivity sessions that involve more than 
just a local and remote station. ITU-T Recommendation 

30 H.231 (see ITU-I Recommendation H.231, MULTIPOINT CONTROL 
UNITS FOR AUDIOVISUAL SYSTEMS USING DIGITAL CHANNELS UP 
TO 2 Mbits/s, 1994) describes such units and their 
various configurations. Attendant Recommendation H.243 
(see ITU-I Recommendation H.243, PROCEDURE FOR 
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ESTABLISHING COMMUNICATION BETWEEN THREE OR MORE 
AUDIOVISUAL TERMINALS USING DIGITAL CHANNELS UP TO 2 
Mb its/ s, 1994) describes the specific operations 
performed in a multipoint call environment, such as 
5 adding, dropping, and viewing specific conferees from the 
conference. These recommendations serve as the impetus 
for the logically defined multipoint control operations 
incorporated into the VMCS server (VCO) architecture. At 
time of writing, there exist fewer than a half-dozen 
10 widely available devices supporting a significant subset 
of the procedures outlined by the recommendations. 

VCO Multipoint Control Operations 

Support for multipoint operations by the VCO 
requires the use of a multipoint control unit (MCU) . 

15 These devices have a number of NIUs, referred to as 

ports, that allow many audiovisual connectivity stations 
to attach to them concurrently — the MCU serving 
primarily to bridge the signals from one station to that 
of many others, so as to enable a group to view an 

20 individual. A specialized algorithm determines which 

conferee, at any given time, is to be seen by the others. 
In most cases, the strength of the audio signal (voice 
presence) determines the individual that addresses the 
conference. A chairman is specified to direct the 

25 conference, and he possesses special privileges to 

administer its outplay; his responsibilities as chairman 
include the appropriate allocation of resources, the 
creation of conferences, and the configuration equipment 
as needed. 

30 The multipoint control operations supported by the 

VCO MultiCall SCI Member are shown below (see FIG. 30) . 
Calls to this MultiCall member map to the PDI 
DevMultiConnect member, one that provides an actual 
physical implementation for them. To support the 
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operations, this PDI member will typically be constructed 
to issue vendor-specific commands to a MCU resident in 
the station , or cabled to it with some communications 
link. All of the major operations needed to directly 
5 control the mechanics of a conference, as its chairman, 
are included. Further discussions of these operations are 
provided in the source code (see section entitled VDI 
Header File in Appendix) . The CALLPARAM structure in the 
VCO has a number of flags and variables used to track and 
10 configure multipoint control operations. A series of 
flag values referred to as MUI/TI CALL.STATES provide 
detailed indications as to very specific states in both 
the local VCO, and the conference in which it is 
participating. 

15 VCO IMPLEMENTATION PROCEDURE 

The procedure to implement a VCO differs 
depending on whether the project is to create an initial 
server component, or to create a new component (from an 
existing one) that will work on a new multimedia 

20 connectivity sub-system. While primary (initial) VCO 
development requires considerable effort, secondary 
(subsequent) VCOs are comparatively minor projects in 
both time and resource requirements. The development of 
VCO clients can proceed concurrently with, and 

25 independently of, that of the server (s) ; the production 
of VCO Clients requires markedly less design and 
development expertise than is required to produce the 
VCOs themselves . 

VCO Implementation Sequence 

30 The following procedure is applied to primary VCO 

development. Secondary VCO development efforts (based on 
the same design) reuse almost all components, without 
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modification, thus steps 1, 3, 4, and 5 are not necessary 
to create them. 

1) Derive VCO Design 

Prefatory to development of a VCO, a detailed 
5 design for a specific implementation must be 

derived from this disclosure of the VMCS 
Technology. In addition to describing the 
internal mechanism, this design provides the 
definitions of the external interfaces to 

10 client applications, and to other VCOs 

created to run on different types of host 
stations; these specifications should be 
preserved for all subsequent implementations 
to maintain interoperability across the 

15 network. 

2) Establish Sub-system Operability 

It must first be determined if the 
connectivity sub-system and associated 
devices are operational. Any test procedures 
20 and test programs must be executed on a sub- 

system installed and configured exactly as 
specified by the particular VMCS server (VCO) 
design discussed in step 1. 

3) Develop Virtual Device Interface 

25 Source code development for the VDI includes 

creating all of the classes from which it is 
derived. The device-independent portion of 
the VCO is implemented as a distinct unit 
that can be built without any dependencies on 

>. 

30 any device-dependent, or vendor-specific 

components • 

4) Develop PDI Shell with Emulation Support 
Source code development of the PDI proceeds 
initially as an attempt to create a minimal 

35 implementation that will support emulation 
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for its pure virtual device control 
overrides. Calls for device support return 
"Not Implemented" , or if the VDI has invoked 
emulation mode, they return an emulated 
5 response, as if a device was physically 

present. 

5) Debug VCO as Emulation Object 

Running in emulation mode, the VCO is 
debugged to verify the functionality of its 
io device- independent portions. A small sample 

client application must be created to invoke 
SCI members for testing purposes. 

6) Develop PDI Physical Device Controls 

Once the VCO is fully operational and 
15 debugged under emulation, physical device 

control is added to the PDI by providing a 
software linkage of the pure virtual device 
control overrides with the connectivity sub- 
system and associated devices previous 
20 emulated in software. Media Control Objects 

are implemented, tested, and integrated into 
the device control system. 

7) Debug VCO as Live Device Control Component 
Running in the default device control mode, 

25 the VCO is debugged to verify the 

functionality of all of its components and 
features in a "live" connectivity 
environment. A sample client application must 
used, as in step 5, to invoke SCI members for 

30 testing purposes. 



DEPLOYMENT 

This section describes usage of the disclosed VMCS 
technology in an operational configuration. 
Consideration is given to the underlying theories of VMCS 
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operating principles, including discussions relating to 
the sequences of operations needed to manage various 
multimedia connectivity tasks encountered during VCO 
connectivity sessions. In essence, the following section 
5 serves as an operations manual for the VMCS, focusing 
mostly on the services provided by the VCO. 

OPERATING PRINCIPLES 
CONSTRUCTION 

VCO construction is a process defined by C++ as a 
10 means to create a binary software object from a class 
definition. With the VCO, the client initiates a 
construction process that is in no way different from 
that of any other class, and the VCOPARAM data structure 
is initialized, along with other initialization tasks. 
15 Upon successful construction of the Virtual Connection 
Object, its principle data structures and capabilities 
are available for perusal. 

• Construction gives the client access to VCO 
internal data structures, use of basic 

20 device-independent services, and the results 

of a perfunctory examination of requisite 
supporting sub-components • 

• By the time VCO construction has completed, 
its dispatcher is running, and it has 

25 uploaded all configuration parameters from 

backing store. At this time, the notification 
mechanism is fully operational, and Notifier 
Objects can be created for use by the client. 

• Following VCO construction, the VCO terminal 
30 input and output ports are active, and can be 

used by the client to send text messages to 
output devices, or to decode command input. 
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• Although the VCO may have successfully 
constructed, no drivers have been loaded, no 
devices have been accessed/ initialized, and 
there is no way for the client to know if the 

5 hardware necessary to run this VCO is 

actually installed* 

DESTRUCTION 

VCO destruction is a process defined by C++ as a 
means to destroy a previously constructed binary software 
10 object. With the VCO, the client invokes a destruction 
process that is in no way different from that of any 
other class. During the process of VCO destruction. . . 

• If the VCO is connected, a disconnect is 
issued — the VCO waits until the disconnect 

15 completes — and all associated VCO 

components and drivers are unloaded. 

• The VCO dispatcher is halted, and any 
Notifier Objects are deleted, thus 
Notification Receiver Objects in the client 

20 will no longer receive information. 

• The terminal, and all other VCO services, are 
no longer available for client use, since the 
VCO does not exist following destruction. 

NOTIFXCATXON 

25 Once a client constructs a VCO, it can create a 

number of Notification Objects, the maximum of which is 
determined by the system designer. Notification 
indications are sent to the client immediately following 
construction, should any triggering events should occur. 
30 • The NewNotif ier command enables the creation 

of a Notifier Object, returning the handle to 
one just created as specified. When the 
Notifier Object is created, it is intimately 
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associated with one particular Notification 
Receiver Member contained within one 
particular Notifier Receiver Object, neither 
of which can be changed; a new Notifier 
Object must be created to direct notification 
to a new object-member combination. 
The DeleteNotif ier command can be used to 
delete Notifier Objects, the handle of the 
Notifier Object being used to identify the 
instance to delete* 

The EnableNotif ier command can be used to 
enable or disable the specified Notifier 
Object. Each Notifier Object can be disabled 
to stop the VCO notification process to that 
particular Notifier. When enabled and 
actively receiving notifications, a call to 
the client's Notification Receiver Object (by 
the Notifier Object) occurs to prosecute 
indication of the occurrence of an event, 
during which time, it cannot be reentered by 
another such call until it returns from 
processing that event currently in play. 
The SetNotif ierTriggers command allows the 
client to change the set of events that cause 
the Notifier Object to trigger; that is, 
invoke the Notifier Object to deliver 
information to a specific member function of 
a specific class object, indicating that a 
particular VCO event has taken place. 
The TriggerNotif iers command can be used to 
trigger one particular Notifier Object, 
unconditionally, or to present an event to 
the triggering mechanism, allowing it to 
trigger all Notifier Objects for the VCO that 
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contain that specific event in their 
triggering profile. 

• Notifier Objects cannot be created or deleted 
while processing the notification of an 

5 event , because the internal list of Motif ier 

Objects is locked. However, the triggering 
profile for the Notifier Object can always be 
modified. 

CONFIGURATION/ SYSTEM SETUP 

io There are two distinct services available to VMCS 

system users for configuration/ setup. The first is the 
ability to maintain a VCO initialization file that stores 
a text record describing all of the startup defaults for 
major categories of VCO settings, including a description 

is of its network service, standard terminal output device, 
local station identity, dispatcher rate, device and 
connection time-outs, conference profile, and other 
default settings. The second is the ability to invoke 
dialog boxes containing detailed configuration/ system 

20 setup utilities that are provided for each of the four 
possible media types (audio/ video/ image/data) that are 
potentially handled by the VCO. 

• The initialization file is read at VCO 
construction time, and its user-readable text 

25 arguments are converted to an internal binary 

format stored in the VCO, accessible as a 
data structure to VCO clients. 

• The SetConf ig command allows clients to write 
a new configuration structure to the internal 

30 VCO configuration structure, and at the same 

time activate the new settings. 

• The RefreshConf ig command allows clients to 
upload the VCO's internal configuration from 
its default initialization file, and at the 
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same time activate the new settings. 
Alternately, the command can bie used to 
upload the internal configuration stored in 
the initialization file into a client 
configuration record, leaving that of the VCO 
configuration record unmolested. 
The StoreConfig command enables clients to 
store a configuration record directly in the 
default VCO initialization file, overwriting 
the existing configuration, or alternately, 
it enables clients to similarly store a 
configuration record held privately by the 
client. In either case, the data elements in 
the configuration record are converted to 
user-readable text arguments prior to being 
stored in the initialization file. 
Integral configuration utility screens enable 
end users to adjust relatively minor vendor- 
specific device driver and operating specific 
system parameters that do not map well to the 
generalized, device- independent controls 
offered by the VDI and associated media 
control device control settings. 
The VMCS concept intends these adjustments to 
be limited to those settings that are usually 
set once during initial system installation, 
and subsequently left mostly alone; they are 
settings that tune and enhance the operation 
of the standard VCO device control 
operations, and are not intended to duplicate 
or replace them. 

The strategy behind these utility screens is 
identical to that used by advanced 
microcomputer operating systems, employing 
graphical user interfaces, whose printer 
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device driver designs require an integral 
"setup dialog" to enable the user to 
configure the specialized hardware features 
of a target printer device, prior to sending 
the job to the print queue* 
As specified by the system design, 
configuration and setup parameters adjusted 
in these utility screens are used to set the 
device default settings that are later 
manipulated through standard SCI calls to the 
device control sub-system. Moreover, vendor- 
specific configuration files are modified 
here via links to their particular private 
software component configuration scheme. 
The SetupAudioDevices command invokes the 
audio setup utility, which provides 
adjustments for microphone input sensitivity, 
frequency equalization, output gain, 
specialized physical input/output port 
selection, noise filtering, and recording 
options. 

The SetupVideoDevices command invokes the 
video setup utility, which provides camera 
adjustments such as white balance, access to 
test modes, NTSC/PAL mode selection, and 
focusing mode selection. Additional 
adjustments for video display include those 
that affect color, tint, hue, brightness, 
horizontal alignment and vertical alignment. 
The SetupImageDevices command invokes the 
image setup utility, which includes output 
settings for any hardcopy display/printer 
device, or video display adjustments for 
factors similar to those in the video setup. 
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Input settings for imaging devices typically 
relate to form size and ambient lighting. 
• The SetupDataDevices command invokes the data 
setup utility, which is more nebulous in its 
5 specific format, and whose settings may range 

from communications port settings to disk 
drive specifications for backing store. The 
VMCS make no presumptions as to the ultimate 
use of data streams, thus the derived VMCS 

10 design must specify the data setup utility. 

Typically, a VCO that directs a data stream 
to/from a communications port will maintain 
settings for baud rate, parity, stop bits, 
and other asynchronous data transmission 

15 settings . 



TERMINAL SERVICE 

The VCO terminal service provides an input and 
output port. The terminal output port functions as a 
standard output device that displays character stream 

20 data written to it, while the terminal input port accepts 
character stream data written to it, and interprets it as 
VCO text commands. Character stream data takes the form 
of null-terminated ASCII strings, referred to as text 
messages* The null character is used to denote the end of 

25 the message. Format dictates VCO text command strings 
terminate with a carriage return, and intervening nulls 
that terminate command (sub- strings) are ignored by the 
decoder . 

• Text messages sent to the terminal output 
30 port may be written, concurrently by the VCO, 

to more than one physical output device, 
following each client text output operation. 
Physical output devices configured to be 
written when text messages are sent to the 
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VCO terminal output port, are referred to as 
attached (to the output port) . Resultantly, 
clients sending text messages to the default 
VCO terminal output port will find that the 
same text message has been duly written to 
all output devices attached to the terminal 
output port. 

Text messages sent to the terminal input port 
are parsed into string command and argument 
tokens, and interpreted by the VCO as 
representations of SCI commands. Once a text 
command has been fully decoded, it is used to 
affect SCI member functions, thereby 
providing a scripted control mechanism to any 
VCO client; scripts can be generated by the 
local client, read from script file, 
transmitted from a remote client across a 
connection, or entered directly from a 
terminal • 

The terminal service is available immediately 
following construction. A default output 
device is identified in the configuration 
stored in the VCO initialization file, and 
attached to the terminal output port. 
A range of standard output device types can 
be added or removed from the list of output 
devices attached to the output port. All 
output devices are written with every text 
message that is sent to the terminal output 
port . 

The ToTerminal command is used to send an 
optionally formatted text message to the VCO 
terminal output port. The command functions 
similarly to "print" statements used by 



98/09213 



PCT/US97/15018 



- 146 - 

various programming languages that send text 
to a standard output device. 

The FromTerminal command is used to send an 
optionally formatted text command (VCO script 
command) to the VCO terminal input port. NOTE 
THAT the terminal input port cannot be read 
for input by the client, as the term input 
refers to the provision of input data to the 
VCO from the client. The client is the source 
of the character stream • Since the VCO has no 
reason to request commands from the client 
(only the client can initiate the issuance of 
commands) the onus is on the client to send 
those commands to a mutually agreed-upon 
place where the VCO can receive them, and in 
so doing, invoke the VCO to decode them* 
Reiterated more plainly, the client "stuffs" 
script commands in a buffer, and calls the 
VCO to interpret them. 

A Notifier Object may be created and utilized 
as a terminal output device. When the 
Notifier Object is attached to the terminal 
output port, it may be triggered by any VCO 
(or client) text output sent to the terminal 
output port, thereupon the Notifier Object is 
explicitly triggered so as to make the 
client's Notification Receiver Object the 
recipient of every text message sent to the 
terminal. This mechanism allows any client to 
direct all text message output to a client's 
text processing routine. 

NETWORK SESSION 

Establishing a network session is accomplished by 
nvoking a seguence of SCI members. Construction and 
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destruction of the VCO frame the connectivity session in 
that a VCO is usually selected and constructed just prior 
to connecting to a remote station, and is subsequently 
destructed immediately following the termination of the 
5 connection to it, therein freeing all system resources 
erstwhile allocated to the maintenance of that 
association. The process of associating two stations 
across the network, for the purpose of exchanging audio, 
video, image, and binary information between them, is 
10 advanced by a sequence of VCO operations next described: 

• The Open command initializes the encapsulated 
multimedia connectivity sub-system, loading 
and starting all supporting vendor-specific 
software components. Until the "open" is 
15 performed, only non-device related VCO 

services are active. All devices are started 
and tested to determine that they are fully 
operational. All available signals are 
represented in newly created Media Control 
20 Objects, and then are opened for use. The 

entire sub- system, including all hardware and 
software components, is set to default 
startup settings, and the network connection 
is verified. If the open is successful, a 
25 connection can be established at any time, 

and all local devices are accessible to the 
client, to be controlled by the user. 
Incoming calls from a remote station may be 
handled following a successful open. 
30 • The Call command initiates a call to a remote 

station. In the preferred VMCS embodiment, 
the network is the ISDN (telephone system) 
and the "call" operation results in a direct 
dialing of the number of the remote stations 
35 line(s). Just as with a standard telephone, 
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the visual telephone service provided by the 
VMCS requires no further action by the 
client, and a simple result is returned. A 
successful connection process results in the 
execution of an internal VCO process to 
establish a series of baseline operating 
modalities for the type of session 
established. For the visual telephone, a 
video window is displayed showing the far 
end, remote station audio is audible, and 
both local video and local audio are sent to 
the remote station. Image and binary data 
facilities are initialized as idle, and 
pathways await client operations to exchange 
information. In short, the "call" operation 
of the VCO's visual telephone system works in 
an identically analogous fashion to making a 
"call" with a standard analog telephone: 
dial, connect, then concurrently exchange 
information bi-directionally, without delay. 
The MultiCall command enables the initiation 
of a number of complex multipoint control 
operations (see FIG. 30). If the local 
station is the conference chairman, the VCO 
client can add and remove conferees from the 
conference, among other administrative 
functions, all of which require the ability 
to control a multipoint control unit (in some 
direct or indirect fashion according to the 
actual physical implementation of the VCO 
service) . Other multipoint operations include 
various query and broadcast operations that 
may or may not require an advanced level of 
MCU control. The client can query any of 
these operations to determine if they are 
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currently supported by the session in 
progress* The client can determine if the VCO 
implementation supports the operations at all 
by examining the VCO capabilities list, which 
5 includes multipoint control capabilities that 

are proprietary to VMCS technology. 
• The Hangup command enables the client to drop 
one, or more (all) lines used for the current 
call. Similar to the "call" operation, the 

10 "Hangup" operation of the VCO's visual 

telephone system works (by default) in an 
identically analogous fashion to the "Hang- 
up" of a standard analog telephone: end the 
call without delay. 

15 • The Close command shuts down all devices in 

the multimedia connectivity sub-system, and 
unloads all vendor-specific software 
components. All client access to device 
control services is no longer available, and 

20 Media Control Objects are all destructed. 

Neither incoming, nor outgoing calls may be 
handled, and only the non-device related 
services remain active. 



MEDIA DEVICE CONTROL 

25 Device control is available to the client by the 

manipulation of Media Control Objects via calls to the 
MediaControl SCI member. The VCOPARAM structure contains 
a list of the names of all available Media Control 
Objects active in the system. This list will be empty if 

30 the VCO has not been opened first, as the list of Media 
Control Objects reflects the signals available for 
manipulation by the client. A list of the handles to 
these Media Control Objects is also available, and 
information about them may be obtained using the 
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appropriate SCI member function. Principles governing the 
control of the devices in the encapsulated sub-system, 
and their associated operations, are shown below: 

• There are four signal types (audio, video, 

5 image, data) and four signal directions (to 

remote, from remote, to device, from device) 
from which sixteen Media Control Object type 
permutations are derived. These are the 
sixteen default Media Control Object types 
io that may be addressed by type in operations 

(see FIG. 7A) . 

• Following successful completion of a VCO open 
command, any available signals in the VCO are 
represented as Media Control Objects, 

is automatically opened for use, and enabled. 

They are not switched on initially, but must 
explicitly be turned on by a client command 
or by connection to a remote station. 

• The MediaControl command enables clients to 
20 change the settings for any active (existing 

and enabled) Media Control Objects assigned 
to be one of the sixteen default types. 
Additionally, switching of signals (in the 
form of plugging together source and 

25 destination Media Control Objects) , creating 

composite signals from multiple input 
signals, and a host of related functions can 
also be accomplished with this command (see 
section entitled VDI Header File in 

30 Appendix) • 

• The SetDef aultMco command can be used to 
assign a non-default Media Control Object as 
a default Media Control Object, if it is the 
same type as the one it is replacing. 
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• The GetMcoHandle command can be used to 
retrieve the handle to an Media Control 
Object from its name label or object type. 
GetMcoLabel is a command that allows the name 

5 label for the Media Control Object to be 

determined from its handle, 

• The GetMcoParam command can be used to 
retrieve the internal parameters and settings 
for a specified Media Control Object, and 

io thus it can be used to determine the 

operational states and settings of the signal 
represented by the Media Control Object, as 
well as the device (if any) that is the 
source or destination of that signal. 

15 BINARY DATA OBJECT EXCHANGE 

Data objects may be exchanged with single 
operations, between stations that are both running a 
VMCS; each of which fully understands the data formats 
and transport layer" protocols of the other end. For 

20 now, such issues are left to resolution by the system 
developer who must determine the exact protocol used to 
transfer the VCO' s data objects as described herein. 
Though lacking in international standardization, 
manipulation of binary data objects is operationally well 

25 defined and described to client applications by the VMCS 
(The Software Control Interface and the logical 
manipulation of which is clearly implemented in the 
"session layer* residing in the VDI) . Fortuitously, the 
ITU is currently working on Recommendation T.120 (Data 

30 Conferencing) to enable standards-based exchange of 
binary data objects. A case could be made for the 
utilization of this VMCS model for all connectivity 
software systems on the sole basis of its ability to 
insulate applications from the ongoing T.120 
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specification, and the complexity of its implementations. 
As of this writing, T.120 remains incompletely specified, 
only partially implemented by any real products, and even 
less well understood by system developers. It is expected 
5 that T.120 will eventually provide the "language" 

necessary for the VCO to conduct its "binary data object 
exchanges" below the " session layer" , in an entirely 
standards-based fashion. 

If the remote station is not running a VMCS, 

10 simple data buffers and cursor positions may be sent 

according to existing procedures for information sharing 
in H.320, but support to transfer entire binary and/ or 
text files may not be available. If it is determined that 
the remote station connectivity sub-system is a 

15 compatible VCO (using the IsVCO command) , then any data 
object can be transferred. Otherwise, if the data object 
to be transferred is a file, the remote station will be 
unable to respond to the VMCS proprietary file transfer 
protocol used on the data channel. Support for the 

20 exchange of cursor positions, facsimiles, still pictures 
(images) and raw data buffers is supported by most H.320 
compliant stations, and thus possible between a VMCS and 
any remote station to which it may be connected. The 
mechanics of exchanging data objects between stations are 

25 discussed below: 

• The Transfer Buffer command enables a client 
to send a buffer of binary data through the 
data channel (or multiplexed data channel 
using an allocated portion of its total 

30 bandwidth) , to the remote host. This command 

can also be used to determine if the data 
channel to the remote station is available. 

• The Transfer Object command enables a client 
to send or retrieve a specified data object 
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through the data channel, or multiplexed data 
channel . 

• The transfer operations specify a Media 
Control Object whose data signal is used to 

5 transport the data. If the remote station is 

running a VMCS, the direction of Media 
Control Objects signal determines whether the 
transfer operation sends local data to remote 
station (data to remote) or is a request to 
io retrieve data from the remote station (data 

from remote) . 

• The Media Control Object used for the 
transfer contains data structures and 
variables that describe the actual status of 

15 the transfer. 

SYSTEM INFORMATION 

Access to system information is highly restricted, 
from the view of the client, and is only available 
through SCI members. These members handle a wide variety 
20 of VCO states and parameters, and provide that 
information to the client in divers formats: 

• A number of VCO states and conditions are 
reported by SCI members returning boolean 
results. These boolean test members allow 

25 clients to determine if the VCO is ready to 

make a call, if a call is currently being 
setup, if a call is connected, if a 
multipoint call is in progress, if the remote 
station is a VCO (running a VMCS) , or if the 

30 current VCO exists in more than one instance. 

• References to copies of data structures, 
stored internally in the VCO, are returned 
for those specific categories of information 
relating to devices, configuration, call, 
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protocol, control, and monitoring parameters. 
One member returns a reference to a copy of 
the entire VCO system information data 
structure . 

5 • The internal data structure of a Media 

Control Object can be accessed in a way 
similar to other data structure, with the 
client specifying the default Media Control 
Object type, or a handle to one. Also, the 
10 handle for a Media Control Object can be 

obtained from a Media Control Object label or 
the Media Control Object* s type. 

• Text names for most enumerations, constants, 
and system objects can be retrieved from the 

15 VCO using any one of a number of members 

designed to return labels to them. 

PROTOCOL MANAGEMENT 

The H.320 protocol defines the basic operational 
structure of the VCO's multimedia connectivity services, 

20 and from the standpoint of the client, is mostly 

transparent to its functionality. An exception lies in 
the VCO support for the manipulation of device modes and 
capabilities; it is useful for the client to affect the 
system's capability list, as well as the set device modes 

25 directly. Moreover, such access allows more knowledgeable 
clients to perform advanced, or less well supported 
operations at a low-level. 

• A data structure in the VCO, referred to as 
PROTOCOLPARAM, provides the client with 

30 information about the H.221 multimedia 

connectivity protocol. A full accounting as 
to the progressions of which, is provisioned 
by this useful data structure, specifically 
with regards to current and pending device 
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modes for audio, video, data, and 
miscellaneous operations. 

• The SetConf Prof ile command enables the client 
to specify a conference profile that 

5 describes a preferred set of audio, video, 

and data modalities (relative to the 
available bandwidth of the connection) that 
define the overall quality of the 
connectivity session. 

10 • The SetModes command enables the client to 

specify one, or more, H.221 device modes by 
presenting them to the connectivity sub- 
system. This command is used in conjunction 
with the VerifyBandwidth command to determine 

is if there is sufficient bandwidth available in 

the connection to support a specified set of 
audio and data modes, while retaining the 
current video mode. 

• The SendCaps command enables the client to 
20 transmit its entire H.221 capability list to 

the remote station. 

• The SetDeviceTimeout enables the client to 
specify the number of milliseconds the 
Network Interface Unit should wait for a 

25 response from a network request before timing 

out, whereas the SetConnectionTimeout enables 
the client to specify the number of 
milliseconds the system should wait for a 
connection to a remote station to complete 

30 prior to timing out. 



VCO CONTROL OPERATIONS 

A large group of operations enables the client 
application to adjust, control, and invoke special 
features of the VCO. Some of these operations enable the 



WO 98/09213 



PCT/US97/15018 



10 



- 156 - 

manipulation of internal VCO settings that are typically 
left to their default settings for most sessions. A 
number of commands are used by a client to attach to a 
remote VCO for the purposes of remote control and/or 
5 remote monitoring of it. 

• The EnableVco command is used by the client 
to alter the state of the VCO's "enable" 
flag, a task usually reserved for recovery 
from an exception that previously disabled 
it. The SetVcoExceptMode is used to set the 
exact modality used by the VCO to handle 
exceptions. 

• The SetVcoTraceMode command is used to 
instruct the VCO as to exactly which 

is operations and components should be 

configured to direct trace information to the 
VCO terminal output port, 

• The EnableMultiCallOps command is a simple 
switch that is used to select the client' s 

20 accessibility to the multipoint control 

operations. To disable these operations 
causes them to return "disabled" to the 
caller. 

• The EnableDispatcher command is used by 

25 clients to pause the dispatching of events 

from the VCO event queue. This operation is 
used when the client wishes to "idle" the 
VCO, while allowing underlying devices to 
function as best as they may. The related 

30 command SetDispatcherRate enables the client 

to change that rate at which events are 
dispatched from the VCO event queue, a task 
usually performed when a faster or slower 
event stream is required by the client 

35 application; faster dispatching rates allow 
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the client to operate at speeds closer to 
those of the encapsulated multimedia 
connectivity sub-system. 

The UpdateCapsList command is used by the 
client to add or remove a device capability 
to the VCO device capability list, a version 
of which is transmitted to the remote station 
during the connection process* A related 
command, UpdateModeCapsXRef , allows the 
client to add or remove a mode-capability 
cross-reference record that is used when the 
VCO attempts to establish common operating 
modes with its remote station peer. 
The EmuControl command enables the client to 
access an internal VCO emulation facility. 
Features include enabling/disabling the VCO 
device emulation mode, and invoking 
predefined emulation sequences. 
The AttachToRemote command is used by the 
client to provoke the VCO to attach to its 
remote station peer, if that peer is a VCO 
(running a VMCS) . The DetachFromRemote 
command eliminates any attachment between 
interconnected VCO peer stations. When the 
VCO is attached, the SetVcoControlMode 
command is used to select the master, slave, 
or peer modality of operation for the local 
station, with respect to the remote station. 
The SetVCOMonitorMode command enables the 
client to select the event stream for the VCO 
to process. Events from the local station, an 
attached station, a group of stations, or 
some combination of station are directed into 
its event queue for subsequent dispatching. 
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The SetStationLabel command is used to assign 
a text label to the local station so that it 
may be referenced (locally or by a remote 
station) by that name. 



5 SAMPLE CLIENT APPLICATION 

Source code in this disclosure (see section 
entitled Sample VCO Client Application in Appendix) 
illustrates the use of VCO services by a multithreaded, 
event-driven VCO Client application. This simple program 

10 does not utilize a graphical user interface , but directs 
its output to the standard output console. The program 
examines a VCO's capabilities to determine if it supports 
required audio , video , and data modes, and opens a 
connectivity session if it does. Source code is also 

15 provided for the many header files used by both the VCO 
Clients and the VCO itself. 



The invention is meant to cover all of the above- 
mentioned alternative approaches as well as others not 
specifically mentioned. The above-mentioned embodiments 
20 and others are within the following claims. 
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SOURCE CODE 
VDI HEADER FILE 



VIRTUAL DEVICE INTERFACE HEADER FILE 
for 

VIKTVALIZED MULTIMEDIA CONNECTION SYSTEMS 
ABSTRACT 



This source module contains deftmomu for the principle software enumerutoni. constants, data structures and member fa*o nn t 

~l ,n 2*"* ^ cUcM and "™ enna » ^ any VMCS imptememtuoa. in some form of cau^?i™? t 
dev,CC «««PO««« .re internal <non-publ,c> ,o the VCO. and are of the pure vtnuTr™ AH*E 

member functions, structures, and comoaa shown below are used by every VCO to enable structured access uTmeu^Jx™^ 

same. These m«^rfuncnoru and member data objects are couecoveiy referred to as the Software Control tmerfacT^^ me 
»n*for every VCO mrniementanon. thus enabling creanon of dcv^^^em conneeovny .pplicanons^c e^L!^ 



3505 (SOURCE FILE: VDLH) 



, _ . PROGRAMMING NOTES 

I ^% COnmm »»w«i commemi usug me • #/ * now>on to denote cotnmems ( in addioon 

to me standard C comment notation using " /• •/ •). * WHWB 

2. The term uitfnowit refers to a value, condidon. or requested operation that can not be identified: that is the usage of this word 
connotes a patently erranx condition. E 



3515 LTr" t™"™*""'* ***** 10 a cwrfmon. or requested operaaon thai is idemifabie. but is inappropriate given the current 
3515 set of preconditions: thai is the usage of this word connotes inappropruuencsi of conceal- we «ut«ii 

4. The term txctpnon refers to an occurrence of a seventy that warrants abandonment of me eornecbvirv sub-system fa fatal error)- 
such an occurrence connotes sigtufscant tteseabdizatxon of the VCO has occurred and further usage risks a system crash. 

3320 3. Tht term tlockmg describes calls that watt for the requested operation to fully complete, the return value of which indicates its 
^r^T ° f tt T ^ f ° r lU If *"» » * ' JsBmcaing- argument to me call. and h u set «o 0 

I^ii ^ rem ™ " nmtdl * tt,y w,mou « wa,Dft « for operation to complete, typtcaliy returning -periling " if the request 

^ V ^^^ aoon U(olhe °< ^ opentoon comes from the msemon of a desenpove event into the VCO event queue upon 

3525 

6. All chancier potmen (char*) point to mdl-tenmneied ASCII strvxgs of a length ieu than 256 diameters, including the out*. 
c^eTu{£^^ except that „ «oy ™ ™, MpaC€J ^ m UngTh u lc „ ^ J2 

3530 

ARGUMENT SYNTAX 
for 

VIRTUAL CONNECTION OBJECT EVENTS 

3535 ^S^^Z^T^ °, f . * Wmal ConnCCOCn ° b > w e ™ « tmoated when a noaficaoon object in the host VCO 

e£TI 'J^JTT^ * haiidling function residing tn a destgmucd Notification Recover Objea <NROl; 

ftatu, a sofrware object dm contains rnember functions unpatented specifically to respond appropriate iv to that type of system 



3540 EVENT IDENTIFIER PARAMETER 1 PARAMETER 2 



NuHErent Don't care 

NtwEnauSutt True if cmutanon cnahled 



Don't care 

Don' l care 

NewEmuOp < EMUlATIONOP > Don't care 

3545 New^fCoum Pre**** reference count New reference count 

NewDevteeSute < DEV1C ESTATE > Device mdea 

< MOT TYPE > Ptr m med« cm ob, Ubel 

NcwLocalCapi Prenoux number capabilities New number capamlines 
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3550 



3555 



3560 



3565 



3570 



3575 



NewRemoteCaps 

NewRevModc 

NcwXmtMede 

NcwReJModt 

NtwAudioSctting 

NewVklfea5cttittc 

NewlmageSetting 

NewDaiaSctting 

NcwCaUSUte 

New! tnclStau 

NtwtintlSutc 

NewC«ofProlUe 

Ntv/DtscStatus 

NcwMultfCallSteic 

NewMuUiCallOp 

NewDataXfcrSuu 

NcwRcvBufler 

NtvXmtBuffcr 

NtwRcrObJect 

NewXmlObjtct 

NewVcoStatt 

NewCurserPot 

NewTerminpin 

NewTcrmOutpm 

NewResultCode 



Previous number capabilities 

< BASCODE > 

< BASCODE > 

< BASCODE > 

< MCO SETTING > 

< MCO^SETnNC > 

< MCO SETTING > 

< MCO SETTING > 

< CALLSTATE > 

< UN ESTATE > 

< UNESTATE > 

< CONFPROFILE > 

< RESULTCODE > 

< MULTICALLSTATE > 

< MULTXCALLOP > 

< XFERSTATE > 
Number of byte* received 
Number of bytes transnuaed 

< MCO XFEROBJ > 

< MCO XFEROBJ > 

< VCOSTATE > 
High-word is X. low-word is Y 
Number of bytes transmitted 
Number of bytes Kniumtaed 

< RESULTCODE > 



New number capabilities 

Don't care 

Don't care 

Don't care 

Parameter for 

Parameter for seamg 

Parameter for setting 

Parameter for seamg 

Don't care 

Don't care 

Don't care 

Don't care 

Don't care 

Don't care 

Don't care 

Ptr to media art obj label 
Ptr to media ctrt obj label 
Ptr to media ctrt obj label 
Psr to XferObjeei 
Ptr to XferObjeei 
Don't care 

True if relative to previous 
Pit to message string 
Pit to message soing 
Ptr to invoking cmd string 



// BASE DATA TYPES USED IN ALL VCO SOURCE MODULES 



3580 



3585 



typedef unsigned 

typedef unsigned 

Typedef unsigned 

rypedef const 
typedef 
typedef 



char 
tm 
long 

DWORD 
DWORD 
DWORD 
DWORD 



BYTE: 
WORD: 
DWORD: 
BASCODE; 
EVENT: 
HNOTTFIER: 
HMCO: 



// 8-bit unsigned value (standard octet) 
// 16-bit unsigned value 
// 32-bit unsigned value 

// 32-bit unsigned H.221 bit-rite allocation signal constant i 
// 32-bit standard VCO event identifier type 
// 32 -bit handle used to reference signal objects 
// 32-bit handle used to reference media cert objects 



" tMPLEMENTATTON ^DEPENDENT CLASSES DEFINED ELSEWHERE 

class XferObjtct: // Base class for all transfer object descriptors 



3590 32-BIT STANDARD VIRTUAL CONNECTION OBJECT EVENT IDENTIFIERS 



3595 



3600 



3605 



3610 



3615 



EVENT NuBEveat 
EVENT NewEcottStaie 
EVENT New£m*Op 
EVENT NewRcfCottnt 
EVENT Nev/DericcSutc 
EVENT NewMcoFecus 
EVENT NewLocaJCape 
EVENT NtwRcsttoteCaps 
EVENT NewRevModc 
EVENT NewXmiMode 
EVENT NewRejMode 
EVENT NewAudmSctting 
EVENT NewYldfoStcttDf 
EVENT NewlmageSetting 
EVENT NewDataSetting 
EVENT NcwCaUSUte 
EVENT NewUnelState 
EVENT NewUnelState 
EVENT NewCooJPtofUe 
EVENT NewDiacStatua 
EVENT NewMuhlCaUState 
EVENT NtwMulUCalrOp 



0x00000000: // 
0x00000001; // 
0x00000002; // 
0 x00000004; // 
0x00000008: // 
0x00000010: // 
0x1)0000020:// 
0x00000040: // 
0x00000080: // 
0x 000001 00: // 
0x00000200: // 
0x00000400;// 
0x00000800: // 
0x00001000: // 
0x00002000: // 
0x00004000; // 
0x00008000; // 
0x00010000; // 
0x00020000: // 
0x00040000: // 
0x00080000; // 
0x00(00000; // 



NO-OP to event processor 
New VCO cuulation sate 



New 



New 
New 



New 



New 
New 
New 
New 



New 
New 



New 
New 
New 



VCOrefe 
media control device state 
"current" media ctrt Object has been set 
local capability list available 
remote capability list available 
device mode set by remote staoon 
device mode set by local staoon 

to set device mode rejected 
setting for audio object 
setting for mooon- video object 
semng for imaging object 
semng for bitsneam object 
call state 
line I state 
2 sate 

conference profile for call 
disconnect status from network 
multipoint call state 
multipoint call operation complete 
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3620 



3623 



3630 



3635 



3640 



EVENT 
EVENT 
EVENT 
EVENT 
EVENT 
EVENT 
EVENT 
EVENT 
EVENT 
EVENT 
EVENT 



NewDauXferSute 

NewRnrBmTtr 

NewXrulBnfTrr 

NrwRcvObject 

NewXmlObject 

NewVcoState 

NcwCunorFos 

NewTtnninput 

NewTermOutput 

NewRcsuhCodc 



-» 0x00200000; // New data transfer state 

- 0x 00400000 : // New data buffer receive complete 

• 0x00800000; // New dam buffer nnsraitstan complete 

- OxOJOOOOOO: // New data object receive complete 

- 0x02000000: // New data object transmission compter* 

- 0x04000000: (I New global VCO state 

- 0x08000000; // New cursor position from remote station 

- Ox 10000000: // New text message to VCO (to VCO terminal input port) 

= 0x20000000: // New text message from VCO do VCO terminal output pom 
™ to *J***5°? " New resutt coae from mterpreted VCO command 

- 0x80000000: // Reserved mtpiemenanon-dependeru event 



NUMERICAL CONSTANTS 



mt 


MaxDeviees 




2: 


ira 


MaxObjFerDev 




3: 


im 


MaxMcoType 




16: 


int 


MaxXRef 




3: 


mt 


MaxModei 




100; 


tra 


MaxCaps 




100: 


cm 


MaxUncs 




2; 



// Max number encapsulated devices 
'/ Mix number media cot objects per devtcc 
// Max number of media coi object types 
// Max number mode-cap rets per record 
// Max number total H.221 device modes 
// Max numoer total H.221 device capabilities 
// Max lines manageable by call controller 



ENUMERATED CONSTANTS 



// VIRTUAL CONNECT OBJECT GLOBAL OPERATIONAL STATES 
3643 typedef emim ( 
VooOpen. 
VeoOoaed. 
VcoFaikrf. 
VcoDiaabied. 
3630 VcoScxteEnd 
) VCOSTATE; 



// VCO is ininalrrrd and operaoonaj for calling 
// VCO is not operaoonaj; no calls possible 
// VCO experienced failure, but is sundl operaoonaj 
// VCO has been disabled and is no longer operational 



3653 



3660 



ft EXCEPTION HANDLING MODALITY FLAGS 
typedef eoum ( 

ExeeptModeDebug * OxOl. 

ExccptModeUser » 0x02. 

ExceptModeTerrn - 0xO4. 

ExccptModcNoufier - OxOS. 

ExccptModeAboft - 0x10 
} EXCEPTMODE: 



// True enables output debug in/o in msg box for exception 
// True enables output 'user" info in nug box for exception 
// True enables sending exception info to terminal devices 
// True enables reporting of excepnon by triggering nooiier 
// True enables abort of ops. and disables VCO on excepnon 



// TRACE OUTPUT MODALITY FLAGS 
typed ef cnim ( 

TraoeModeDevicc - 0x01. 

3663 TraccModcr4enfter - 0xO2. 

TraceModeMCO - 0x04. 

TrxeeModcCaD - OxOS. 

TraceModeLinc - Ox 10. 

TnceModeProto - 0x20 
3670 } TRACEMODE. 



// True enablea all low-level device tra 
// True enablea nodfscanon event nace output 
// True enables media cert object nscc output 
ft True enables high-level call control nee output 
// True enables low-level call and line state trace output 
// True enable all protocol oace output 



3673 



// VCO CONTROL MODALITY FLAGS 
typedef crsjm ( 

CtrlModePeer - 0x01. 

CcrtModcMxxter - 0x02. 

CtxlModeSUve - 0x04. 

} CONTROLMODE: 



// True sets local direct local access possible 

// True sea local as master to control remote VCO 

// True sets local as slave to remote VCO 
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3680 



3685 



3690 



3695 



3700 



3705 



3710 



3715 



3720 



3723 



// VCO MONITOR MODALITY FLAGS 
rypedcfenum< 

MouModcLocat - 0x01. 

MonModeRemoce - 0x02. 

MonModeAmy * 0x04 

1 MONTTORMODE; 



// True sea monitoring to include local suoon 

// True sea motutonng to include remote soma 

II True sea motutonng array of taoons in conference 



// TERMINAL OUTPUT DEVICES FOR ATTACHMENT TO VCO TERMINAL OUTPUT PORT 
fypedef emtm ( 
TcnnOOevNonfier - 0x01. 



TcnnODcvFire 
Tc rmO De vSareaxn 
TermODevMCO 
} TERMODEV; 



- 0x02. 

- 0x04. 

- 0x08 



// VCO EMULATION OPERATIONS 
cypedef entm ( 

DisaWeCaUEmuMode. 

EnabieCaUEmuMode. 

SetCaUDtrSnmon. 

SciCailDscMcu. 

Exccpnon. 

LinelDisc. 

I inr2Qisc. 

RandamUnctDisc. 

R«ndoml,rnc2DUc. 

LinelRing. 



UmlRiftgbecfc. 
Liiie2Rmgbacfc. 
UnelCoanect, 
LinelConnecc 
On 



TwoUxKlncoming, 
OaeLineOutgotng. 
TwoUneOutgotng. 
OneLmeOtiojotngfiusy. 
TwoUneOuujomgBusy. 
OiteUncOutgouigRcj. 
TwoLmcOutgotngRej. 
TwoLmeFttUCallThcnDucRqsu 
OneLineAudioOnly . 
OneUneAudioVideo. 
TwoLmeAudioVideo. 
TwoUneAudmVideoDaa, 
r»nFrmitinonOpEnd 
) EMULATIONOP; 



// Noafier as cermmaJ ouzput device 
// File, or file system std device, as terminal output device 
'/ System data itreim as terminal output device 
// media Ctrl Object as terminal output device 



// Disable VCO call emulation mode 
// Enable VCO call emulation mode 
'/ Set remote host as a user-sonon 
II Set remote host as an MCU 

// Emulate faal VCO execpaoo (recoverable in this case) 
// Emulate disc on line 1 
// Emulate disc on line 2 

// Emulate doc on line 1 at random tune fw/in I nun) 

// Emulate disc on line 2 at random tune (w/in 1 mini 

// Emulate ringing on line 1 

// FjnHlatr ringing on line 2 

// Enauase rwgbeck os line I 

// Emulate nngbacfc on line 2 

'/ Emulate connect on line I 

// Freulifr connect on one 2 

// Emulate 1 line incoming call 

// Emulate 2 line incoming call 

// Emulate 1 line outgoing call 

// Emulate 2 line outgoing call 

// Emulate 1 line outgoing call to busy remote 

// Ecaulate 2 line outgoing call to busy remote 

// Emulate 1 line ounmmg call that is rejected by remote 

// Emulate 2 line outgoing caU that is rejected by remote 

// Eamlate 2 line call to connect, the disc rqst by remote 

// Exudate 1 line audio-only call 

// Emulate 1 line audio-video call 

II Emulate 2 line audio-video call 

// Emulate 2 line media cut call 
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// MULTIPOINT CONTROL OPERATIONS ftTU-T H.231. ITU-T H.243) 




waim \ 

SetConfFocus, 


// Set conference focus to specified station 


3730 


QueryConfFocus. 


// Determine season currently in conference focus 




StfCoofChatr 


// Set conference chairman 




yUMJMHIlWlCUa 






AddSouson, 


// Add station 10 conference 






// Remove union t mm nnf>m» 


3735 


BroadcastAudio. 


// Enable/Diublc hmnirm rtf trv~a| itidm fft f nnfprpp< 




BroadcastVideo. 


ft Enable/Dixxbtc broadcast of local video to conferees 






// Enable/Disable broadcast of local data to conferees 






// Get number of conferees 




GetSeshonList. 


// Get bst of conferees 


3740 


GciScanonCaps. 


// Get list of conferee caps Dilutes 




GetSouionAudjo. 


// Get >w * w from narneiitir ennferec 




GetStabonV ideo. 


// Get video from particular conferee 




OftStatkmOata 


// Get data front parucutar conferee 






// Get numbers and (if possible) label for remote station 


3745 


MntnCiJlOpEnd 




} MULTICALLOP: 






// VCO UNIVERSAL RESULT CODES 






rypedcf enum ( 






Pi dure. 


If Operation failed for some unspecified reason 




Success. 


// Operation completed successfully 




Pending, 


// Operation ts pending: standby for completion 




TimedOui 


^^pera&on omed out 






// Operation sets mode or value that is already in force 


37S5 


Reauesii3eiued 


// OnMinAn mwi>M» hit* <4«>ntM4 fnr crime iMtm 




Notlmnietnented 


ft ^^peraoon is not yet tittpjetncrnnd* but is f ortfacoTrung 




NotSunponed 






PtDCCSsTCRSlDUBd 4 


// Operation **»pf f*! on process ***^t baa been terminated 




Capable. 


// System capable of requested operiuiott/coniiguracon 


3760 


Incapable. 


// System not r?piH* of requested ope ration/ configuration 






tt Specified object onus be opened prior to operenon 




MustBeClosed. 


// Specified object must be closed pnor to operation 




Disabled. 


/ / Specified function disabled to prevent further system corrtxpoon 


3763 


InUse. 


// Specified object resource ts in use by another process 




// Queue is empty (no removable objects available) 




QueueFuIl. 


// Queue is full (no more objects can be inserted) 




h4etnory Alloc Error > 


// Memory not be itHireatrfl to support ope radon 




ResourccAlloc Error. 


// r^*pr ndcru resource f mild not be **lft**ned due to error 






// Some twexnecied tenant internal error was detected 


3770 


TonerFairarc. 


// Could not configure omer to modulate processing 






// Operation result indeterminate: don't know what happened 




InralidSoxicsa. 


// Specified atmun has invalid spec, or is for some reason unknot* 




IxnraUdDaaType. 


// Daza specified for arg is of wrong type: such as a null ptr 




InvaiidDeviceAestrn. 


// Return code from device driver is unexpected or unknown 




LnvaJidOpcreoon. 


// Fnu me rated operason/ event is unknown 




bnalidOpefmoaiiNow. 


// Enumerated operatxou/cvent is known, but unexpected at dus ox 




lovaiidCapabiliiy. 


// Specified capability ts unexpected or unknown 




InvalajModc. 


// Specified mode a unexpected or unknown 




lnvaUdLiac. 


// Specified line is unexpected or unknown 


3780 


InvalalNotifici. 


// Specif ted nonftcr is unknown 




InvaiidObject, 


// Specified object is unknown 




InvalxlScf&ng, 


// Specified scamg ts unknown for this object 




lmralidParmm. 


// Specified parameter is unknown for this scmng 




CmdSynauLEnor. 


// Syntax error in * command " portion of message 


37S3 


ArgSyrnxxJError, 


// Syntax error in "arg* pomon of message 




NotEaougnBxnd width. 


// Not enough bandwidth for requested operaoon 




CiIlMustBeCannccatd. 


// Operation only possible while connected to remote station 




NoCaUForUneAdd. 


// AjDsmpt to add unknown conferee 




LoelsDown. 


// Line has disconnected 


3790 


LneCoxmectFaUed. 


// Line connection failed 




LiocNocConncctBd, 


// Line has not yet fully connected 




UneuBusy. 


// Line is busy 




DtafonntctRcojucst, 


// Line disconnect is requested 
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3795 



3800 



3803 



3810 



3815 



3820 



3825 



// DISCONNECTION RESULT CODES 

DiscScumUndefmed. 

DurSnruiNomal. 

DiscStaoisP rococo! Error. 

DiscSaiui_0 PrcfixNotAllowed. 

DiscStaws_ 1 .PrefuNcMAIlowcd. 

DiscStaouf l"Prefi»Requirtd. 

DtseSttoulnvalidNumter. 

DocSaaulnvaiidAreaCode. 

DiscStaajiNurnberOianged. 

D is r .Sttt u s ftemoicBusy , 

DiscSouusNoAnswer. 

DiscSttauCiIUUjccscd. 

D isrSaru sRernoteUravailaolc . 

DucSamaNerarortEfTor. 

DiscSaauOUIPmnpccd. 

DucSa&aOuawngfianetf. 

nitrSnniflrroniiiiiDini il 

DiicStt a u Q iulttyUnaymiUMe. 

DiicSuusCoinputcrRscUnivaiable. 

DueSuaaHWConTigunaonEnor. 

DiseSatusQunNoddle. 

DtacSuQuChanTypeNotlmpteffl, 

DiscStaojsFactfityNc*Subsenbed. 

Disr.Srin iTFictiityNoilmpicm, 

DucStatusNoRootToDest, 

DiKSafltulnvmiidNumberFonnat. 

DiicSaauNumberfUqutred. 

P-TUtrTortcFiirt 
) RESULTCODE: . 



FROM NETWORK 
Disc 
Disc 
Disc 
Disc 
Disc 
Disc 
Disc 
Disc 
Disc 
Disc 
Disc 
Disc 
Disc 
Disc 
Disc 
Disc 
Disc 
Disc 
Disc 
Disc 
Disc 
Disc 
Disc 
Disc 
Disc 
Disc 
Disc 



LAYER 
sous indicates 



sunt] indicates 
sous indicates 
tutus indicates 
sows indicates 



scams indicates 
stasis indicates 
status wwjirurt 



status indicates 
soois indicates 
mass indicates 



stains indicates 
status indicates 



soots indicates 



undefined condition 
normal 

protocol error 
zero prefix is pot allowed 
one prefix is not allowed 
one prefix is required 
invalid number 
invalid area code 
number has changed 
remote line is busy 
no remote answer 
remote rejected call 
remote a unavailable 
network error 
call preempted by other call 
out goin g calls are barred 
incoming calls are barred 
requested quality unavailable 
eontputer resource unavailable 
hardware configuration error 
channel not idle 
channel type not implemented 
facility not subscribed 
facility not unplensemed 
no root to desonanoo 
invalid number format 
number required 



ENUMERATED CALL CONTROL CONSTANTS 



3830 // INDIVIDUAL UNE STATES 



3835 



3840 



3845 



I rnr Disconnected, 
LtneDtaled. 



LioeJting, 
UncRingback. 
LineCortnecxed. 
LineSateEnd 
} UNESTATE: 

// GENERAL CALL STATES 
typedef enum { 

CallDiseennecied. 

Call Connecting. 

CaUCormecsed. 

CallSateEnd 
} CALLSTATE; 



// Unc is disconnected 
// Lane rs dialed 
//Line is busy 
// Line is ringing at local 
// Line is ringing at remote 
// Line is connected 



// Call it fully c 

// Call is in die process of connecting 
// Call is fully i 



ti CALL DESTINATION 
3850 rypedef enum { 
NoDetnnanon. 
LocalSctQon. 
RemoteStanon. 
LocalMCU. 
3855 RemoteMCU. 
} CAIXDST: 



// No specific call destination determined 

// Call to local staoon (uicommg call) 

// Call to remote soman (outgoing call) 

// Call to local mulnpouu control urut (incoming call) 

// Call to remote saoon (outgoing call) 
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// MULTIPOINT CALL STATE FLAGS 





rypcdtf enum ( 




3860 


UMtdtiConneccsd 


- 0x0001. 




UConfFocus 


- 0x0003. 




UCosfChiir 


« 0x0004. 




URcvmgConfAudto 


« 0x0008. 




IsRcvingC on/Video 


» OxOOtO. 


3865 


IsRcvingConfData 


a 0x0020. 




UBnfrnnng Audio 


« 0x0040. 




IsBrdcaanngVidco 


- 0x0080. 




IsBrdcasdngDasa 


= 0x0100 



) MULTI C ALLSTATE ; 

3870 

// CONFERENCE CONNECTIVITY PROFILE 
rypedcf enum ( 

UscAudioOnty, 

UseVideoQnly. 
3873 UseDauOnly. 

BcstDataOnly. 

BestAudioOnly. 

BesVtdeoOnly, 
) CONFPROFTLE; 

3880 

// DATA TRANSFER STATES 
typedef enum { 
XferReady. 
XfemngDaou 
3883 XferRetrytng, 
..- XferPaused. 
XfcrFailurc. 
XferNot Rrinnnrt i iig . 
XferixueniaiError. 
3890 } XFERSTATE; 

// MEDIA DEVICE CONTROL STATES 
rypedef enum { 

DeviccOpen. 
3895 DevieeOosed. 

DevtceFsiled. 

DcviccBusy. 

DcviccMCIFailurc. 

DcviceNotRciponding. 
3900 DcvtcejjuernalError. 
) DEVI CEST ATE: 



// Local stanon n connected to more man one remote (or MClfi 

II Local stanon has comcrencc focus 

// Local stanon u conference chatrmin 

// Receiving conference audio 

// Receiving conference video 

// Receiving conference dau 

// Broadcasting local tudto 

// Broadcasting local video 

H Broadcasong local dan 



// Audio soaring only 

ll Video sharing only 

// Dam sharing only 

// Pnoray to data sharing qualify 

// Priority go audio sharing quality 

// Priority to video sharing quality 



// Ready to oansfer (idle) 

// Transferring data 

// Transfer retrying 

// Transfer paused 

// Transfer failed 

// Transfer process not responding 

//Transfer process internal error 



// Device is ininilimrt and operational 
// Device is not operational 
// Device failed 

// Device is already in use and unavailable 

// Device driver failure (Media Control Interface failure) 

// Device is not responding 

// Device traemal error detected 
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3903 



START CONTINUOUS LINEAR ENUMERATION OF MEDIA CQKTRO LOBJECT CONTROL TOKENS 



3910 



3913 



3920 



3925 



3930 



3933 



3940 



3945 



3950 



3955 



" MEDIA CONTROL OBJECT TYPES 
rypedef enum { 

Audioln - o. 

AudioOut. 

AudmSrc. 

AudmDu. 

Videoln. 

VitaOut. 

VidooSrc. 

VideoDu. 

bnageln. 

ImageOut. 

ImageSrc. 

ImafcDsi. 

Detain. 

DactDui. 

DataSrc. 

DataDst 

ObjTypcEad 
} MCO JTVTE; 

// MEDIA CONTROL OBJECT SIGNAL TYPES 
typedef enum < 

Signmlln - ObjTypeEnd. 

SigraKhiL 

SipuOSrc. 

SignalDst. 

SigralTypeEnd 
} MCO_SICTYFE; 

ff MEDIA CONTROL OBJECT COMPOSITE TYPE 



" Audio signal from remote station 
// Audio lujnai to remote luoon 
// Audio signal from local device 
// Audio signal id local device 
// Mooon*video from remote moon 
'/ Morion-video to remote souon 
/' Morion-video from local device 
" Morion-video to local device 
11 Image from remote sraoon 
// Image co remote stanon 
// Image from local device 
// Image to local device 
// Bit stream from remote stanon 
" Bit saeam to remote staoon 
// Bit stream from local device 
// Bit stream to local device 



// signal from remote staoon 



typedef enum { 
Discreet - SignaiTypcEnd, 



Muttitttexcd, 
Demuttiplcaed. 
Transformed. 
CompositeTypeEnd 
J MCO.COMPTYPE; 

// DATA TRANSFER OBJECTS 



XferNoObjcct - CompositeTypeEnd. 
XferCunorPos. 
XferSotng. 
XrerTexiFile. 
XterfimFile. 
XferObjEnd 
} MCO XFEROBJ; 



// 

11 «g»I fwm local media control device 
II signal to local media comrol device 



// Multiple inpua to same multiple outputs 
// Multiple inputs mixed into complex single 
// Multiple inputs encoded into single output 
// single input decoded into muiopte outputs 
// single input subjected to specific transform 



// No specified data transfer object 

// Cursor Position 

// NullHermtnate ASCII text srxtng 

// Text file 

// Binary file 
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// MEDIA CONTROL OBJECT SETTINGS 
typedef enum { 

// BASE OBJECT SETTINGS 
3960 NoSeang - XferObjEnd. 

Open. 

Qosc. 

Enable. 

Disable. 
3963 On. 

Off, 

AttachTo. 
DctBchFrom. 
AdoTcComposiie . 
3970 Remove FromCarnposite. 
SetComposittVType . 
GetSwui. 
GrtTipi, 

3975 // MOTION-VIDEO SETTINGS 

SetColorkey. 

AssignWindow. 

UouxtgnWixidow . 

ResizcWtndow, 
3980 SetStnttehOn. 

SctSn-etcbOff. 

SetbnageTypc. 

Fr e eze . 

Unfieuv. 
3983 SetProponxonalOn. 

SctProponxonalOff, 

SclVidcoFrameSize. 



// No specific setting 

// Open object (initialize and render operanonaJ) 
// Qosc object 

// Enable object (make available for use) 

// Disable object (make unavailable for usct 

// Turn on object signal 

// Turn off object signal 

// Attach object signal to another object signal 

// Detach object signal from another object signal 

// Add object signal to composite signal 

// Remove object signal to composite signal 

// Set modality of composite signal 

// Get status of object signal 

// Get capabilities for object 



// Set mooon-video color-key vahie for display 

// Assign motion- video display to specified window 

// Unassign mouoo-video display from window 

If Resize (refresh and rcangn)motion-vtdeo window 

// Set monon- video stretch mode on 

// Set mooon-video saesch mode off 

// So motiop*victco image type 

// Freeze munott-video signal 

// Unfreeze mocum-vidco signal 

// Set mooon-vtdco proporoonal mode on 

fl Set monon- video prepomonal mode off 

// Set video frame size 



// IMAGE SETTINGS 
3990 /• AssignWindow. 

UnauignWmdow . 

ResizeWindow. 

SctSoetcbOa. 

SetStretcnOff. 
3993 SeclmageType. •/ 

SeilmageMetnc. 

SetPixelWidm, 

SetPixeiHetghu 

SciPixeiDepth, 
4000 SetPfaysicalWidm. 

SetPnystcalHeighi, 

SctHorzPuclOhgin. 

SetVenPixelOrtfin, 

SeoMorzPtiysicalOrigttv 
4003 SetVenPlryixcalOrigin. 

SetHorzPbielDeswiy. 

SetVenPixelDennty . 

Vil m ag rC ombmeType . 

4010 // AUDIO SETTINGS 
SctAttdioQuality. 
LtpSyncaOn. 
ljpSyncfaOff, 
EcnoCancctOn. 

4015 EchoCaacelOrr. 

SciDTMFDuimuon, 
LocaJDTMFPulsc. 
RonotcDTMFPuUe. 



// Assign imaging display to window (already defined above) 

// Unassign imaging display from window (already defined above) 

// Resize (refresh/realign) imaging window (already defused above) 

// Set imaging sxreoUi mode on (already defined above) 

// Set imaging screech mode off (already defined above) 

// Set imaging image type (already defined above) 

II Set imaging image metric type 

II Set imaging image pixel width 

// Set imaging image pixel height 

// Set imaging image pixel depth 

// Set imaging image physical width 

// Set untying image physical ***'g h* 

// Set hnnrnriri l image pixel origin 

// Set vertical image pixel origin 

// Set horizon tal image physical origin 

// Set vertical anage pixel origin 

// Set honxotttzi image pixel density 

// Set vertical image pixel denary 

// Set image combine type 



// Set audio signal qualify 

// Turn on lip^tyncimmizaoon of audio signal to video signal 

// Turn off lip-rynchroaioacn of audio signal to video signal 

// Turn echo canceilanon on 

// Turn eciu> cancellation off 

// Set dial tone m o d u I toon f reouency pulse duraoon 

It Pulse DTMF at local staoon 

// Pulse DTMF at remote station 



4020 



// DATA SETTINGS 

SfiDinRate. 

SetSyncXferMode. 



// Set data transfer rate 

// Set synchronous data transfer mode 
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SeiAsyiKXferModc. 
SetftcstnctedMode. 
4025 SetUnrestncnuiMode. 
McoSe rang End 
} MCO.SETnNG: 

// BASIC IMAGE TYPES 
4030 rypcdef crura ( 

Nolnuge * McoScrnngEnd. 
Colorlmage. 
Grayscale image. 
BitonaUmage. 
4035 lmageTypeEnd 
} IMAGETYPE: 



// Set asynchronous dan muster mode 
// Set restricted data transfer mode 
// Set unresmcted data transfer mode 



// No image available 
// Color image cype 
// Grayscale image type 
II Two-tone image r/pe 



// IMAGE METRICS 
rypcdef enura ( 
4O40 lnchMetncs - lmageTypeEnd. 
CcrmMcmci. 
MitfiMcxries. 
MicroMetnc*. 
ImageMethcEnd 
4045 } EMAGEMETRIC; 



// Sec "inch* as primary measure 
II Set "centimeter" as primary measure 
'/ Set "millimeter' as primary measure 
// Set "micrometer* as primary measure 



// IMAGE -ON -IMAGE COMBINE TYPES 
rypedef count { 
Overlay » ImageMemeEnd. 
4050 Replace. 

Colorftvey. 
Outline. 
BUwtseOR. 
BttwneXOR. 
4055 BirwtseAND. 

ImageCombmcTypeEnd 
) IMAGECOMBTYPE; 

// MOTION-VIDEO FRAME SIZES (ITU-T HJttl) 
4060 rypcdef emtm { 

NoVideo - IrnagcConimneTypeEnd. 
QuanerCIF. 
FuBCXF. 
CIF240. 
4063 40F. 

VidcoS tze End 
) VIDEOSIZE: 



// Overlay desunaoon with source 



// Overlay desonanon defined by colorkey with source 
// Overlay desoaaoon with temporary outline of source 
// Combine destination and source with bitwise OR 
// Combine destmaoon and source wim bitwise XOR 
// Combine desunaoon and source wim bitwise AND 



// No video signal 

// Oiancr-uze Common Intermediate Format video image 
II Full-size Common intermediate Format video unagc 
// Common uueiuietluue Format video image with 240 scant mei 
// Four-crow Common Itttermediate Format video image 



// AUDIO SIGNAL QUALITY 
4070 rypcdef enum { 

NoAudio - VideoSazeEnd. 
VoiceLow. 
VoiceHigh. 
Music. 
4075 HighFkteihy. 

AudioQuaJicyEnd 
} AUDIOQUALXTY: 



// No audio signal 

// Low qua! try voice signal (usually 8 khz sample rate) 
// High Quality voice signal (usually S-Ukhz sample rate) 
// Music quality signal (usually 22 khz sample rate) 
II High fidelity quality signal (usually 44khz sample rate) 
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II DATA TRANSFER RATES 



4080 


DaoJUteNone - AudioQualtcyEnd. 


// No dan transfer 




Daortate30Q. 


11 300 baud transfer rate 




DaoJUtettOO. 


It 1200 baud transfer rate 




DantfUte4800. 


// 4800 baud rotifer rate 




Dat*Rate9600. 


// 9600 baud transfer rate 


4085 


DataRweUKb. 


// 14.4 kilobaud transfer rate 




DataRauOSKb. 


// 2S.8 kilobaud transfer rate 




DacaRate64Kb. 


// 64 kilobaud transfer rate 




DaaRatel28Kb. 


// 128 kilobaud transfer rate 




DafaRatel92Kb. 


// 192 kilobaud transfer ate 


4090 


DiflUUte256Kb. 


// 256 kilobaud transfer rate 




D*taRate320Kb. 


// 320 kilobaud transfer rate 




DaaJUte384Kb. 


// 384 kilobaud transfer rate 




DaaIUte512Kb. 


// 512 kilobaud transfer rate 




DataJUte 1152Kb. 


// 1 152 kilobaud transfer me 


4095 


DittRjie 1536Kb. 


// 1536 kilobaud transfer rate 




DataRateEnd 






) DATARATE; 





II LAST VAUD MCO TOKEN VALUE (USED FOR BOUNDS CHECKING OF ARGUMENTS) 
4100 cypedef enum { 



HtdtaControtTokenBui «= DataRateEnd 



4105 END CONTINUOUS LINEAR ENUMERATION OF MEDIA CONTROL OBJECT CONTROL TOKENS 



4110 



4115 



// STRUCTURE FOR VCO EVENT DESCRIPTOR 
struct BgEVENTREC { 

DWORD Id; 

DWORD Paraml: 

DWORD Psram2: 

STATION* pStadon: 

BOOL IsFmmDcvice: 

tagEVENTREC* pNext: 

tagEVENTREC* pPrev; 



// 32-bit VCO event identifier 
// 32 -on event parameter I 
// 32-bit event parameter 2 
// Ptx to source season 

// True if event generated by encapsulated device 
// Ptr to neat event in queue or list 
// Ptr to previous event in queue or tin 



4120 



4125 



4130 



4135 



4140 



rypedef tagEVENTREC EVENTREC: 

// STRUCTURE FOR STATION DESCRIPTOR 
straw np STATION ( 



DWORD 



BOOL 

ogSTATON* 
tagSTATION" 

); 



Id; 

pLabei: 
pNumbcr(3]; 
bVco: 
pNexc 

pPrev; 



// System tdendfier/tndcx used to refer to tots station 

/ Pit to stanon label 

// Array of pas to numbers of remote sahon 
'/ True if remote xanoo is determined to be a VCO 
II Pit q next nation in list 
// Ptr m previous union m list 



cypedef tagSTATION STATION; 

// DEFINmON OF EVENT HANDLING MEMBER FUNCTION 

cypedef DWORD EVENTPROCC 

EVENT Id. // 32-bit event identifier 

DWORD "Paraml. // 32-bii event parameter I 

DWORD ~Param2. // 32-btt event parameter 2 

STATION* j&canon. // Per to descriptor for station originating event 

HNOTTFIEK* hNoofier // Handle to oooAcauon ob}cct triggered by event 

); 
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// STRUCTURE FOR VCO NOTIFIER DESCRIPTOR 



typedef struct ( 
DWORD 



4145 



4150 



4155 



4160 



4165 



4170 



4175 



4180 



4185 



EVENTPROC* 
BOOL 
BOOL 
long 

DWORD 
J NOTIFIER; 



Tngfcn: 

pObject: 

p Member; 

UEnabted: 

OnlyDevtceEvena: 

nTriggcrcd; 

RetumDau: 



* «pe«fytng events that trigger this noafter 
ft Ptr to Nonfter Receiver Object (NRO) 
'/ Ptr to nottfier handler member of NRO 
// True if nonfter ii enabled to trigger 
11 Tnjc nonfter triggers only for device events 
" Number or times nottfier tnggered since last reset 
// Data returned by notification handler member of NRO 



" STRUCTURE FOR RED -GREEN-BLUE COLOR SPECIFICATION 
typedef struct ( 

HSH J** //Red color component 

lllr ? fcen: // Green color component 

I™ // Bhie color cornponera 

J RGBVALUE; 



// State of physical device 
// Ptr to label for physical device 
// Ptr to version string for physical device 
// Number of media col objects utociated with physical device 
,l 10 * rT >y of handles for media Ctrl objs associated with device 



" STRUCTURE FOR DEVICE DESCRIPTOR 
typedef struct { 

DEVICESTATE Sate: 

char* pLabel: 

***** pVcrsion: 

m nObfeco; 

HMCO phMCO: 
} DEVICE; 

// STRUCTURE FOR MEDIA CONTROL OBJECT AUDIO PARAMETERS 
rypedef struct { 

AUDIOQUAUTY Qualhy: // MCO audio quality 

S£o //True if audio Up^nchmnized with video 

? ^ " HMdle m ********* video object 

BOOL UEcnoCancelOn; // True if echo canceUanon w enabled 

> MCO.AUDIOPARAM: V™™*™* " °* To ~ M <**»™ Frequency duration 

// STRUCTURE FOR MEDIA CONTROL OBJECT MOTION- VIDEO PARAMETERS 
rypedef struct ( 

bAsjignedToWin: 
UWinUpdaied: 
IsFroxen: 
Is Proportional* 
lsStRBhcd* 
ImageType; 
VideoSizc: 
pDisplayWm; 



BOOL 
BOOL 
BOOL 
BOOL 
BOOL 

IMAGETYPE 
VIDEOSIZE 
Window 
} MCOJVTDEOPARAM; 



/; True if obj assigned to window 
// True if window aligned w«h source video image 
// True if motton-video is frozen 
// True if moDon-video proporeonal mode is on 
// True if mcroon-vtdeo stretch mode is on 
// Mooon-video image type 
// Moaon-vtdco frame size 
// Ptr to assigned display wendow 
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4190 



4195 



4200 



4205 



4210 



// STRUCTURE FOR MEDIA CONTROL OBJECT IMAGING PARAMETERS 
rypedef struct ( 



BOOL 
BOOL 
BOOL 
BOOL 
BOOL 

IMAGETYPE 

04AGECOMBTYPE 

IMAGEMETRIC 

int 

ant 

ira 

int 

tm 

uu 

uu 

im 

im 

im 

ira 

Window 
) MCO IMAGEPARAM 



IsAssignedToWin: 
UWmUpdased: 
IsFroxen; 
IsPropontonal; 
IsStrctebcd; 
BaxtcType: 
CombType: 
l/nageMetnc; 
PiietWiddi: 
PuelHeight; 
PixdOcpth: 
HorzPixelOrigin: 
VenPiselOrigin: 
H onPixelDenshy ; 
VertPudOeasiry ; 
PtrynaJWidih: 
PhysicalHctght; 
HorxPhystcaiOrigin; 
VertPhyucai Origin: 
pDisptayWin; 



True if objct assigned to window 
True if window aligned with source video image 
True if imaging is frozen 
True if imaging proportional mode is on 
Tme if imaging stretch mode is on 
B*sic image type 
image combine type 
Image primary measure 
linage pixel width * 
image pixel height 
Image pixel depth 
Image bonzonoi pixel origin 
Image vereeal pixel origin 
Image horizontal pixel density 
Image verocal pixel dcnxiry 
Image physical width 
Image pttystcal height 
image borsonnl physical origin 
Image verocal physical origin 
Pv co assigned display window 



4215 



4220 



4225 



4230 



4232 



4240 



4243 



4250 



// STRUCTURE FOR MEDIA CONTROL OBJECT DATA PARAMETERS 
rypedef struct { 

BOOL IsSynchronous: // True if dm transfer u synchronous 

BOOL bRestrictcd: // True if bandwidth is i cnncual 

BOOL IsComposite: // True if pan of composite 

DATARATE TransferRate: // Data transfer rue 

int CompostteRate: // Composne transfer rate (if pan of composite) 

} M CO _D AT AP ARAM : 

// STRUCTURE FOR MEDIA CONTROL OBJECT DESCRIPTOR 
rypedef struct tagMCO { 
char* pLabd: 
MCO TYPE ObjType; 
MCO SIGTYPE StglVpe: 
BOOL IsValid: 
BOOL IsOpen; 
BOOL 
BOOL 
BOOL 
BOOL 
BOOL 
BOOL 

MCO AUDIOPARAM Audio: 
MCO'VXDEOPARAM Video: 
MCO IMAGEPARAM Image; 
MCODATAPARAM Data; 
DEVICE* pDemce; 
) MCOPARAM; 



IsOn; 

IsAttached; 
IsBusy; 



// Ptr to tabeJ for media Ctrl object 
// Media Ctrl object type 
// Media col object signal type 

// True if media ctri object is valid service or place holder 
// True if media Ctrl object open 
// Tme if media cert object a enabled 
// True if media ctri object ts on 

// True if media ctri object is attached to another media carl object 
/' True if media ctri object n pan of composite 
// True if media carl object is busy (unavailable) 
// True if signal is encode or compressed: false if not 
'/ Audio setmtgs pa r a met er Mock (if sudio type) 
// Video parameter block <tf video type) 
// Image parameter block (if usage type) 
// Dan parameter block (if data type) 

// Ptr to struct for device wtth which media Ctrl object is associated 



« STRUCTURE FOR MEDIA CONTROL OBJECT BINDING RECORD 
struct ragMCO BINDING { 
BOOL bCuHi p uitrr ; // True if binding is to produce composite signal 

nStci // Number of source media col objects 



uu 
int 
HMCO 
HMCO 

tagMCO BINDING* 
tagMCOBINDING* 



nDst 
phMcoSrc: 
phMcoDst; 
pNcxu 

pPrev: 



// Number of destination media col objects 
// Ptr to list of handles for source media ctri objects 
// Ptr to list of handles for desnnanon media ctri object 
// Ptr to next binding record 
// Pit to prev binding record 



rypedef agMCO BlNDING MCOBINDING: 
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4ZS5 



4260 



4265 



4270 



" STRUCTURE FOR MEDIA CONTROL OBJECT COMMAND RECORD 
ryixdef struct { 

!1?9-32ZL t# _ T "* : " ***** media col ob;ea type 

nwnprP™ 0 5 etUni: "Seming for mediae*! object 

// STRUCTURE FOR MODE-CAPABILITY CROSS-REFERENCE RECORD (ITU-T H 221) 
rypedef struct ( 

DWORD value; ^ // Mode or capability value to be crcu-rcferenced 

DWORD T*?: v « „ " Numbcr of cross-references for mode or cap 

JXREF? RetTMaOCRefl; // List of referenced mode* or cap, 

// STRUCTURE FOR DEVICE CAPABILITIES LISTING (ITU-T H.221) 
rypedef struct { 

BASCOni: f^i r v // Number of H.221 device capabUmcj 

} DEVCAPS CapfMaxCapsJ; // Luang of H.221 device capabilities 



4275 



4280 



4285 



4290 



4295 



// STRUCTURE FOR CAPABILITIES DATA (mj-T H.221) 
rypedef struct { 

DEVCAPS Local; 

DEVCAPS Remote 

DEVCAPS C 

tm 

*** nCapt; 

XREF CansfMaxCapsI: 

. X**? ModesfMaxModcs): 
I CAPS; 



// Local device capabilities bating 
// R em ote device capabdioes String 
// Cortnecovtty (network interface) capabilities Itsunt 
// Number of cranes in 'Modes to Caps' xref lut 
// Number of entries m 'Caps co Modes" xref list 
// 'Caps to Modes* xref list 
// "Modes to Caps" xref list 



// STRUCTURE FOR MEDIA CONTROL DEVICE PARAMETERS 
rypedef struct { 
tm 

DEVICE 



CAPS 



uu 



MCO BINDING 
HMCO* 

HMCO 

4300 } DEVICEPARAM: 



Devices; 


// 


DevfMaxDevices); 


// 


Cap; 


// 


nMco: 


// 


nAudtoOb}; 


// 


nVideoObj; 


// 


nimageObj: 


// 


oDattObj; 


// 


pMeoUbelQ; 


// 


pMcoBindtnf; 


// 


paMco: 


// 


hMcofMaxMcoTy pe ] ; 


// 



// STRUCTURE FOR 
rypedef struct ( 

BOOL 
4305 BOOL 

BOOL 

BOOL 

BOOL 

STATION 
4310 STATION 

char* 

uu 

uu 

tnt 

4315 ira 
uu 
tnt 

ROBVALUE 
CONFPROFTLE 
«320 J CONF1GPARAM: 



CONFIGURATION AND SETUP PARAMETERS 



UDynxPonabte: 

UMuItiConnectable; 

UMulDlnsantxabie: 

hFmniartng; 



TcnnOuipuiDcvtce : 

ContiectTiiiieout; 

DeviceTimcottt; 

Dispatcher Race: 

SennceB and width: 

nLmesAvailable; 

nUaesRequested; 

CotorKey: 

ConfProftle: 



// True if VCO is dynamically re-loadable at run-time 

// True if VCO supports muiupouu control operaoons 

// True if VCO supports mul&ple concurrent instances 

// True if servtcc bandwidth is restricted 

// True if VCO starts up efnulatmg devices 

// Label and numbers for local simoon 

// Label and numbers for default remote station 

// Default terminal output device or file name 

// Default connection timeout tn msec. 

// Default device nmeout ui msec. 

II Souring dispatcher rate tn msec. 

// Total service bandwidth available 

// Number of lines available 

// Number of lines request for use by this VCO 

// colorxey value for roooon-video 

// Conference profile 
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// STRUCTURE FOR 
typedef struct ( 

CALLSTATE 
4323 CONFPROFILE 

CAIXDST 

RESULTCODE 

im 

BOOL 
4330 BOOL 
BOOL 

mt 
im 

4335 „im 

UNESTATE 
tnx 

STATION 



CALL CONTROL PARAMETERS FOR CURRENT CALL 



Sate; 

CotuTrefue; 

CallDsc 

DiscSasis; 



IsRestncted: 
IsCanSeup: 
UCailmgVco: 



4345 



4350 



4355 



4360 



4365 



4370 



4375 



4380 



4365 




pSadons; 



// Call sate (or erairc call 
// This conference profile 
// Desolation for call 

// Disconnect sous (when in disconnected sate) 

;/ Tot * 1 number of Unci to be used for this call 

// True if thu call u restricted 

// True if this call is setting up 

'/ True if this call destination is another VCO 

// Number of current c on necti on s for this call 

// Tool bandwidth used for this call 

'/ Can connect otneom used for this call 

if Timesiou used for thu call (if applicable) 

II Lmesate for each tine in caU 

ft Tocal number of stations involved in conference 

« Pit to list of conference stations (first is tocal) 



4340 // MULTIPOINT CALL CONTROL PARAMETERS FOR CURRENT CALL 



MULT1CALLSTATE 
BOOL 
BOOL 
BOOL 
BOOL 
BOOL 
BOOL 
BOOL 
BOOL 
} CALLPARAM 



MuinCattSoues; 
IsConfFocus: 
IfConfChair: 
bRcvmgConf Audio 
IsRcvingConrVideo: 
URcvingCoftfPan 
IsBfdcastms Audio 
IsfirdcasungVideo; 



ft Multipoint call status flags 

// True if sanon has conference focus 

It True if sta&on is conference chairman 

// True if station is receiving conference audio 

tl True if sanon is receiving conference wieo 

// True if sonon is receiving conference data 

// True if station ts broadcasting ft'tdi o 

// True if station is brosdeasang video 

tl True if souum is broadcasting 



"STRUCTURE FOR CONNECTIVITY PROTOCOL PARAMETERS (ITU-T H.330. ITU-T H J2l> 
typedef struct ( 



BOOL 
BOOL 
BOOL 
BOOL 
BOOL 
BOOL 
BASCODE 
BASCODE 
BASCODE 
BASCODE 
BASCODE 
BASCODE 
BASCODE 
BASCODE 
BASCODE 
BASCODE 
BASCODE 
BASCODE 
mt 
im 

BASCODE 
BASCODE 
) PROTOCOLPAJRAM: 



IsXamngAudio; 

IsXmnngVideo: 

UXmdngDaa: 

IsRcvmg Audio: 

IsRcvtngVideo: 

IsRcvmg Daa: 

RcvDanJUte: 

RcvAudioMode: 

RcvVideoModc: 

RcvDaaModt: 

XmtDaaAate; 

XmsAudioMode: 

XmtVideoMode: 

XrntOtaModc: 

NewDaaRaor. 

NewAudioMode 

NewVideoMode 

NewDaaMode; 

nMiseXnuMode; 

nMiscRcvModc 



II True if transtiumng audio 
tl True if transmitting video 
//True if transmitting daa 
ft True if rece iving audio 
// True if recervtng video 
// True if receiving daa 
'/ Current receive transfer rate 
// Current receive audio mode 
// Current receive video mode 
// Current receive daa mode 
// Current Transo m transfer rate 
// Current tramnut audio m*df 
// Current rransnut video mode 
// Current transmit daa —w^i r 

" ? ew ? ag xxmizT rate just set (pending XnuDaaRate) 
// Pending audio mode nut set (pearling XmtAudioMode) 
" Tadc ° tntxte < Pending XmtVideoMode) 

// Pending daa mode ion set (pending XmtDaaMode) 
// Number of nwrH i n eous modes set by local sanon 
„ // Number of mi sc el la n e ou s modes set by remote sanon 

MiscXnnMode(MaxMiscModc|: // List of omceUaneous modes set by local sanon 
MiscRcvModefMixMiscModc); // List of imsceltaneotis modes set by local sanon 



// STR UCTURE FOR REMOTE STATION CONTROL PARAMETERS 
typedef struct ( 

BOOL "I"* if «** event stream atacned « remote VCO 

IZZ, OMasicr: n True if controlling remote sanon (master) 

C^ROUMODE 5££ V^r^X^^ 
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// STRUCTURE FOR REMOTE STATION MONITORING PARAMETERS 
typodef struct < 



BOOL 
BOOL 
4390 BOOL 
art 

STATION* 
MONTTORMODE 
MONTTORMODE 
4395 j MONITOR? ARAM; 



ItMOJUIOrSdl 

n Stt t ion; 
pStaoons: 
Modes: 
Caps; 



// Tnie if event stream attached to remote VCO 

// True if monitoring at least one remote station 

// True if monitored by remote sum 

// Number or stations currently motuored 

// Pu- to list of suaons currently monuored 

// Monitor mode seaxng flags 

// Monitor mode capability 'permission flags 



4400 



4405 



4410 



ft STRUCTURE FOR VCO SYSTEM 
rypedef struct < 



INFORMATION (VCO PARAMETER BLOCK) 



VCOSTATE 
tm 

BOOL 
BOOL 

DEVICE? ARAM 
CONFIGPARAM 
CALL? ARAM 
PROTOCOL? ARAM 
CONTROL? ARAM 
MONITOR? ARAM 
} VCOFARAM i 



pLabcl: 


It 


p Version i 


it 


Sate; 


ii 


ReJCoum; 


ll 


IsEmulaofig; 


II 


URcady; 


ll 


Device: 


II 


Conrtg; 


ll 


Call; 


ll 


Promcol; 


II 


ConxroJ: 


II 


Monitor 


ll 
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CLASS VDl 
(Virtual Device Interim) 

Below is the declaration for the VCO Viituil Device interface Class. An nuance of the VDI class must contain, at a minimum, all 
of the public member functions use by VCO clients to establish and control multimedia connectivity sesstom with remote stations 
This class must also comam an instance of a VCOPARAM dan structure, and the pure virtual member declarations for the device 
4420 control member functions that provide device support to the puttie member function u np lmenu nons. The imptememaoons for these 
pure virtual functions idemarked with the Dev<tahet> symbolic naming convention) reside in the Phrsicai Device interface (class 
PDA. The constructor and destructor of dm class, are protected members, and their public interface u vu call from 
constructor/destructor m the more derived class VCO. 



class VDI: protected EVENT { 



4425 



// MULTIMEDIA CONNECTION SYSTEM INFORMATION 
4430 VCOPARAM VcoPara; 

// INTERNAL DEVICE* IN DEPENDENT MEMBERS GO HERE... 

4435 

virtual const char* GelCUssNaantO { return "VD!"; ); 

4440 NETWORK SESSION CONTROL 

-««••--< — - — — — — •■•■--«■-••■■ — ■» — •-•/ 

VDK char- _j>InitFUe m 0 ); 
/* 

4445 USAGE: Construct the Virtual Device interface for the VCO. Initialize VCO parameters and 

sctnags from the specified init i al iza tio n file. Seam devKe-uidependem daa and code 
objects used by VCO. Create the default VCO device event notxrter and son the VCO 
er. 



4450 PARAM: jDlnilFfle ...FUespcc of file that contains VCO startup pa rams & settings. 

RETURN: none 

•/ 

4455 virtual "VDIO; 

/• 

. USAGE: Destruct the Virtual Device interface. Save current settings to die mioaiizaoon file. Close 
the various media art objects, if open. Delete any nooftcrs and stop the VCO dispatcher. 
Free ail r es o ur c es allocated by VCO. 



PARAM: none 
RETURN: 

4465 public: 
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4470 



4485 



RESULTCODE Opea< BOOL liBiociung m I > ; 



USAGE: Prepare the VCO for making call to remore xunon. Irutialue all rned* ctri ojects 
and the»r supporting device control rub-sy stems. Perform preliminary sub-system 
1 and determine level of system runcnonaJiry 



PARAM: .IsBtockmg ...True if oil r, blocking & w,il not return urml complete, or false if 

RETURN Failure «m*tock«ng A return, .rnmedtatcly as -pending-. 

4475 

Success 



TimedOuc 



Memory AUocError 
Resource AliocError 
Internal Error 
Timerfaihire 



RESULTCODE Close* BOOL UBlockang * 1 )♦ 



USAGE: Shutdown me VCO. Stop all service, provided by media ctrl objects and close 
4490 «upponmg device control sub-systems. Free resources allocated for device control. 

PARAM: .^Blocking ...True if call is blocking & will not return unnl complete, or false if 

noD * btockin § A returns immediately as "pending*. 

RETURN: Failure 
4495 Success 



TnnedOut 
MustBeOpened 



4J00 Memory AliocError 

Resource AliocError 
IreernalError 
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4303 



4510 



4313 



4520 



4525 



4530 



RESULTCODE Call( char* 



j>Namberl i 
^Number 2 < 
BOOL ^Blocking • 



0. 
0, 
t); 



USAGE: 



Establish imuai call to remote station, or MCU; create connecovtry session whose quality is 
determined by the highest common denominator of media Ctrl connecovtry services, 
u may be accommodated by both local and remote sunons. a p rclerc n Le as to the qualify of 
this interaction is expressed by each station; subsequently proceeds negotiation, between 
these stations, to establish the most appropriate media device mierconnection modalioes 
requisite to best ful filing (he requests tor specific tat nmes conflicting) conference profiles. 



PAJtAM: jiNumberl 
_pNttmber2 
_IsBlocktng 



RETURN: FaUure 



Pending 

TtmedOut 

MustBeOpened 

Disabled 

InUse 

Memory AllocError 

ResourceAlloc Error 

InteraaiEnor 

TimxrFatlure 

IrtvalidDataType 

NocEnoughfiajidwidih 



...Per to senng wnh number for line 1. null calls default remote station. 

...Pir to string with number for line 2 (if used). 

...True if call is blocking & will not return unni complete, or false if 
non-blocking St returns immediately as 'pending'. 



4535 
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4340 



4545 



4550 



4535 



4560 



4563 



4570 



4575 



4580 



4585 



RESULTCODE MuWCaW STATION* pSttdoo, 
MULTICALLOP Op, 

DWORD ~FW, m o. 
BOOL IsQttery - 0. 

BOOL .Isaiocktog - I ); 

USAGE; Establish mutttpon* call by presemrag a multipart control operaoon request co me 

conroy^ sub-system, while currently connected to multipoim control unit IMCUV This 
funoum allow, a sauon to pamcrpatc in . conference w„h more than two conferee* co 
control a conference, and to direct local/common media cm to/from coiucrees. 



PARAM: 



_Scaboo 
.Op 



_UQuery 
_isfilocking 



Pit to ttaoon descrtptor specifying to which scauon operation applies. 
■Muinpoim eaU control operation specifier. 
.Parameter for specified operation. 

True if call is to query sub-system for operation capability. 

.True tf call is blocking & will not return unoi complete, or false if 
"on-blocking & returns immediately as 'pending". 



MULTIPOINT CALL CONTROL OPERATION USAGE & PARAMETERS 



< _Op > 

GetNumSoriora 
GetStaoonLui 
GetStabonCaps 
GetSooooidcnmy 
...all other ops 



< _f>aram > 

..Pit bo uu to receive count of stations tn conf 

...Ptr o buffer to hold linked list of STATION records 

...Pit to DEVCAPS record 

...Pit id STATION record to rev id of remote station 
...Don't care 



RETURN: Failure 



TniiedOut 



MustBcOpened 

Disabled 

InUse 

InternalError 

(nvalidStaoon 

InvalidDaaType 

InvaiidOperaoon 

InvaJkfOpersoonNow 



CallMustBeCoonected 
NcOflForLweAdd 
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RESULTCODE Hangup* tni nLioc » 0 ); 
4590 /• 

USAGE: Hang-up enure call to remote nation, or MCU: selectively disconnect specified line only. 
PARAM: _nLinc ...Number of tines to disconnect: null bangs up all fines. 

4595 RETURN: Failure 

Success 
TunedOut 
MunBeOpeaed 



4600 IncematEnor 

InvmlidLine 
CallMustBeConnected 
LineiiDown 

LincNotConnccted 

4605 •/ 
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EVENT NOTIFICATION CONTROL 



4610 



4615 



4620 



46Z5 



4630 



4635 



4645 



4650 



4655 



4660 



4665 



RESULTCODE NewNotifterf HNOTIFXER& 
EVENTPROC* 

DWORD 



^hNoUfler. 
j>Mtmbcr. 
^Object. 
EventMauk ■ 



0); 



USAGE: Create new no^caoon object m the VCO linked notification object list. The noofier , 
toauUy 'disabled" followmg cmoon. and must be enabled to trigger. 



PARAM: hNodfter 



-Reference to handle for newly created VCO nooiicaoon object. 
-Pit b> noufier receiver member to process VCO events. 
..Pit k> aooftcaoon receiver object. 
..Mask specifying events chat will tnggcr nonfier. 



jObjeei 

_EvencMask 

RETURN: Failure 
Success 
RequcnDenied 
Disabled 
InvalidDaaType 
lovalidParam 
Memory AJIocError 
IntcfliaJ Error 



RESULTCODE DelettNotifter< HNOTTFIER bNotlTier >; 

USAGE: Delete VCO signal and remove n from VCO linked object list. 
PARAM: _hNooTier •••Handle to signal to be deleted. 

RETURN: Failure 



InvalidDaaType 
InvaJidNoofier 



RESULTCODE EiuW«Notiner( HNOTHTER hNotifter, 

/# BOOL IbEsubkd - 1 ); 

USAGE: Enable or disable sigral from triggering on tu specified triggering i 



PARAM: .hSignal 

RETURN: Failure 
Success 



.Handle to signal to be enabled or disabled. 

..True enables signal triggering: false disables triggering. 



•/ 



Disabled 

InvalidDaaType 

InvalidNoofter 
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RESULTCODE SelNotinerTritgersf HNOTTFIER hNotifler 
4670 DWORD ~EvemMask - 0 ); 

USAGE: Set events chat will trigger signal 

PAJcAM: hNoctfier ...Handle to signal whose trigger events will be set. 

EvcraMaik . . .Mask spec trying events mat will trigger signal . 

RETURN: Failure 
Success 



4675 



4680 

InvalidDaaType 
InvahdNoofttr 

•/ 

4683 RE5ULTCODE TriggerNoUnersf EVE NTREC * _p Event R*c. 

HNOTIFTER 'hNotiner » 0 ); 

/• 

USAGE: Triggers VCO nonfters sentovc to the specified event, or alternatively trigger a specific signal. 
4 *90 PARAM: _pEventRec ...Pxr to record containing event parameters. 



_hNoofier ...If specified, indicates specific signal go be triggered with event, or 

else all matters sensanve to event are triggered. 



4695 RETURN: Failure 



Disabled 
InvaiidDataType 
IrtvaiidNotiftcT 
4700 (nvmlkiParam 
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4703 



4710 



4715 



4723 



4733 



4740 



4743 



4730 



4755 



CONFIGURATION/SETUP CONTROL 

RESULTCODE SclCoo£lg{ CONFIGPARAM* j^Coaflg ); 

USAGE: Set VCO coitfgurawn data for nam object and encapsulated devices. 
PARAM: jjCoafig ...Ptr to record containing new configuration 



RETURN: Failure 
Sueeui 
RequestDenied 
Disabled 
tmlidDaxaType 
InvaiidParam 
interraiError 

4720 TimerFaihire 
*/ 



RESULTCODE 5toreCoofig< CONFIGPARAM" _pCoafl« « o ); 
USAGE: Store VCO configuranon to backing note. 

PARAM: _pConfig .. iPlr to record conuining configuraoon to write to backing store Jf 

none specified, the current VCO config is stored. 



4730 RETURN: Failure 

Success 
ReouestDaued 
Disabted 
InvaladDataType 

IncemaiError 
TnnerFaihuc 

•/ 



RESULTCODE RefresbCoafig( CONFIGPARAM* _pConfi| - 0 ); 

USAGE: Refreshes current VCO configuraoon or configuraoon record from that saved in backing store. 

PARAM: j>Config ...p* » record to rcccrvc configuraoon read from backing store If 

specified, current VCO conxig u refreshed. 



RETURN: Failure 
Success 
RequesiDemed 
Diaabkd 
InvaiidDaaType 
IsraiidPamD 
IntemalError 
TunerFaihire 
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4760 



4765 



4770 



4775 



RESULTCODE SctupAwtioDcvicesi BOOL _bfilockicg m % ) ; 

USAGE: Invokes dutog box to enable interactive setup of audio devices. 



PARAM: _UBlockmg 



RETURN: Failure 



Pending 



ReojuestDented 

NotSupported 

Process Tenrunacsd 

MustBeOpened 

Disabled 

InUse 

Memory AilocError 
ResourceAllocError 
InternalError 



...True it call is blocking Sl will not return until complete: f*fc» if 
non-Mocking Sl returns immediately as "pending". 



4780 



4785 



4790 



4795 



RESULTCODE Setup Video Dencesf BOOL _UBlockinc « 1 ); 

USAGE: Invokes dialog boa to enable inreracove setup of monon-vidco devices. 



PARAM: ^Blocking 

RETURN: Failure 
Pending 



...True if call is Mocking & will not return una! complete: false if 
non-blocking Sc. re turns immedi ately as "pending". 



ReOyUesxDcntcd 

NotSupported 

PrccessTcnutnated 

MustBeOpened 

Disabled 

InUse 

Memory Alloc Error 
Resource All nc Error 
Internal Error 



4800 



4805 



4810 



4815 



4820 



RESULTCODE SetvpistageDevtcesf BOOL _UBlockang ■ 1 ); 



USAGE: Invokes dialog box to 
PARAM: _UBlocking 



RETURN: Failure 
Success 



Redundant 
flrotirif Dented 
NotSuppotted 

MustBeOpened 

Disabled 

ioUsc 

Memory Alloc Error 
ResourceAllocError 
Insemal Error 



mteracove seup of image devices. 

...True if call is blocking A will not return until complete: false if 
non-blocking 4c returns immediately as 'pending'. 
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4823 USAGE: 



RESULTCODE Sctnp0auDev»cc$f BOOL .liBiockinf « l > ; 



4830 

RETURN: Faihirt 



4S35 



^^TZ'ZTi I imBfBCIWe *™POf data connecnv.ty and r*™* adapter 

S^^i^^ " M * llOW °' sy^m i/oZ Setup 

oi network protocol support software resides here. F 

PARAM: JsBlockiBg ^Truc if call is blocking A will not return urmi compicte. or false if 

RETURN: Failure non-blocking * returns immediate* a, -pending-. 



4S40 



4843 



RcqacuDfiucd 

NocSiipportcd 

ProcesiTcrrmnated 

MustBeOpened 

Disabled 

InUse 

Memory Alloc Error 
ResourccAilocError 
imenalError 
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MED1A CONTROL 



4890 



4855 



4860 



4865 



4870 



4875 



4880 



4885 



4890 



4895 



4900 



4905 



4910 



RESULTCODE McdiaConttoK MCO TYPE McoType. 

MCO SETTING 'Setting. 

DWORD ~Panm - 0. 
BOOL UQuery - 0. 

BOOL lUBloeking m 1 ); 

USAGE: Access service provided by encapsulated media control device by presenting media ctri 
control setting to phytic*! device control sub-system. 



PARAM: .McoType 



Pirun 



...Specific media ctri object type for ope noon. 

... Audio- video-data seaing constant specifying requested service 
desired from object. 

...If required, provides parameter necessary to fully specify request t 
media col object. 



IsQuery 
JsBlocking 



.True if call is to query sub-system for operation capability 

...True if call is blocking & will not return nil complete, or false if 
non-blocking Sl returns immediately as *" 

MEDIA CONTROL OBJECT SETTINGS & PARAMETERS 



< _Seamg > < 
BASE OBJECT SETTINGS: 



NoScomg 
Open 



Disable 

On 

Off 

AaacsTo 

DetacfiFrom 

DeachAlt 

AddTcComposne 

Remove FfomCornposite 

SetCemposiieTypc 

GetStttus 



<VifT ips 



...Don't care 
...Don't care 
...Don't care 
...Don't care 
...Don't care 
...Don't care 
...Don't care 
...MCO type 
...MCO type 
...Don't care 
...Ptr to label 
...Porto label 
...Value 
...Adr of Ptr 
for me lvalue 
< 
< 
< 
< 

...< Param 



to which lvalue MCO will be attached 
to which lvalue MCO will be attached 

of MCO to add to lvalue MCO to create composite 
of MCO to remove from lvalue composite MCO 
aed from one of < MCO.COMPTYPE > 
duu will point to parameter block appropriate 
MCO; dot is. a will be ptr to one of: 
MCO AUDIOPARAM > 
MCO VTDEOPARAM > 
MCO IMAGE? ARAM > 
MCO DATAPARAM > 
> to whose capability is directed «>r h inquiry 



MEDIA CONTROL OBJECT SETTINGS &. PARAMETERS CONTINUED 
MOTION-VIDEO SETTINGS: 



SetColorfcey 
AangnWindow 
UoassignWmdow 
ReaxacWindow 
SetSeretcnOn 
SctScmchOfr 
SctlmagcType 
Freeze 
Unfreeze 

SesPnportionalOr) 
SctPropornonaiOff 
ScxVkieoFrameSuc 



...< RGBVALUE > (cast to DWORD argument) 
...Ptr to unassigned window's **** object 
...Ptr to previously assigned window's data object 
...Ptr to previously assigned window's data object 
...Don't care 
...Don't care 

...Value selected from one of < IMAGETYPE > 
...Don't care 
...Don't care 
...Don't care 
...Don't care 

...Value selected from one of < VIDEOSTZE > 
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4915 



4920 



4925 



4930 



4933 



4940 



4945 



4950 



4955 



4960 



4965 



4970 



4975 



IMAGING SETTINGS: 

AsaignWindow 

UiuustgnWindow 

ResacWcndow 

SctSoetchOn 

SetSflTtchQff 

SctlmagcType 

SetlmageMetnc 

SetPixctWidth 

SetPixelHeigbt 

SetPixelDepth 

SctPhysicalWidtn 

SetPhyticalHetght 

SeiHojzPixek3riiin 

SctVcnPixelOrigm 

SetHoncPlmicalOrivin 

SetVenPby*icaiOrigin 

SesHorzPixclDensity 

SctVertPttdDeomy 

SetlmageCorabiDcType 

AUDIO SETTINGS: 

SetAudioQuatiiy 

SyncfaToVideo 

UnjynchFroraVidco 

EchoCaacelOn 

FfhnC a n c ttOff 

SctDTMFDuraooo 

LocalDTMFPulse 

RemoteDTMFPuise 

DATA SETTINGS: 

SetDataRaie 

SctSyacJCferMode 

SetAtyncXfcrModc 

SetitestricwlMode 

SedJiucnnctedMode 



RETURN: Failure 



TimadOut 



ReojucstDcmed 

NocSupported 

PracasTcnninated 



MmBeOpcacd 



MemoryAJlocError 
ReaourctAlloc Error 
InternalEiiof 
TttnerFailiire 

JmtsdDeviccjtentni 

InvaJidOpcraoori 

lnvAiadOpentsonNow 

IfivaJidObjcct 

lnvalidSetBng 

InviladPann 

Nc4EnoughB*ndwidia 



..Pit to unaligned wmdow'i data object 
..Pxrm previously assigned window's data object 
..Pv to previously assigned window's daa object 
..Don't care 
..Don't can 

Value selected from one of < IMAGETYPE > 
..Value selected from one of < tMAGEMETRJC > 
..Integer pixel count 
..integer pixel count 
•»* ttyr pixel count 

" l n8eyCr w«n according to current metnc 
ttmB * cconlm * » current metric 
..integer pixel count (offset from left) 
" l H?ff Cr p,xcJ ccum iott** from np> 
"t ?y Umu * cconiin * 10 current metne (offset from left) 
..imeger utuo according to current metnc (offset from top) 
• l n y P«e» count according to uruo per current metnc 
..Integer pixel count according to units per current metnc 
Value selected from one of < IMAGECOMBIKETYPE > 

..Value selected from one of < AUDIOQUAUTY > 
..Ptr to video obj Ubet to which lvalue obj will synch 
..Ptr to video obj label from which lvalue obi will be unsynch 
..Don't care 
..Don't care 

..integer number of milUsecocids for duration 
. Jaeger representing keypad button 
..Inatger r e pr ric i iun g aeypad buoon 



.Value selected from one of < DATARATE > 
.-Don't care 
..Don't care 
..Don't care 
..Don't care 
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4980 



4985 



5000 



5005 



RESULTCODE SetDefaultMco< M CO TYPE .McoType, 

const char* .pMeeLftbeJ ); 

/• 

USAGE: Set the VCOs default media cert object for the specified object lypc. 

PARAM: .McoType ...Type of maiu end object to which default media ctri object wdi be j 

_pMcoLabci ...Ptrto libel for media col object to set as default. 

RETURN: Failure 



NocSupponcd 
4990 Most&eOpened 

Disabled 
tnUse 

IrueraalError 
InvsiidDataType 
4993 InvaiidObject 

invalidSemng 



RESULTCODE SrtDrfnItMcof MCOTYPE McoType, 
HMCO ~hMco); 

/• 

USAGE: Set the VCO s default media Ctrl object for the specified object cype. 

PARAM: McoType ...Type of meda ctri object to which default medu crrl object will be set. 

J*** 00 ...Handle of media ctrt object to set as default. 

RETURN: Faitun 

Sl hTTf fff 



3010 

NosSupporad 
MustBeOpened 
Disabled 
iaUse 

5015 ImnniError 

InvalidDaaType 

invaiidObject 

InvaiidSetong 

m t 

5020 
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5025 



5035 



5045 



5050 



5055 



5060 



PROTOCOL MANAGEMENT & CONTROL 



RESULTCODE SetC«mfProfuc( CONTPROFTLE _Proffle >; 



u^^n^r^"""* ° r M m pf0 *™' °' «» «« <*< current profile)- *»< 
a. select in aigonthm out selects dev.cc modes most appropriate tn the specific cJype 

3030 PARXM: p rofite ..Type of conference profile desord. 



RETURN: Failure 



NotSupported 
Disabled 



RESULTCODE SetModes( B AS CODE* jiModeUst. 
5040 /• *"* _«Mod««'l ); 

USAGE: Aitempc to set H.22I device modes for call in progress 
PARAM: j>ModeLiii ...Per to list urray) of H.221 mode constants 



io set. 

Number of modes tn list. 



RETURN: Failure 
Success 



laaemalError 
InvalidDaaType 
InvaiidModc 
InvalidParsjn 

CaUMusifieCoonecced 



RESULTCODE ScadCapsO; 



up a call, 
PARAM: none 
5065 RETURN: Failure 



5070 



USAGE: Transmit local capabilities to remote saaon. Musi be connected or m the process of senmg 



MuttBcOpened 

Disabled 

lnternaiError 

LinelsOown 

L mcN otCo nnec c cd 



WO 98/09213 



PCT/US97/15018 



-189- 



RESULTCODE VertfyButdwidtbf BASCODE AudioMod* 

3073 " BASCODE ~DaUM*dch 

/• 

USAGE: Determine if call tus sufficient bandwidth id support the specified combination of audio and 



5093 



5100 



5115 



5120 



5125 



5080 PA-RAM: _AudioModc ...Requeued H.221 audio mode. 

_DataMode ...Requeued H.221 data mode. 
RETURN: Failure 

5085 



NotSupported 
MustReOpened 



llMBimlRlTOf 

5090 Tiznerfaiture 



UndcfmedRcsuu 

InvaiidMode 

CaAMuscBcConneeted 

•/ 

RE5ULTCODE SetDev4ceTuneout( DWORD Msec); 



USAGE: Set default connection umeout value for encapsulated network interface in term* of how Urns 
it will wait for a response from the network. 

PARAM: _Miee ...Timeout value in milliseconds. 



RETURN: Failure 
Success 

3103 MustBcOpened 

Disabled 
ImermlError 
TtmerFs Bore 
InvalidParam 

5110 •/ 



RESULTCODE S c lC op n cct Tlmeout( DWORD Msec); 
/* 

USAGE: Set default connection ameout value for call controller in terms of bow long n will wait for the 
enure call conn e c t i on sequence to complete. 

PARAM: _Msec ...Timeout value in milliseconds. 

RETURN; Failure 



MusxficOpcned 

Disabled 

InvsJidPusm 
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DATA EXCHANGE CONTROL 



5130 



5135 



5140 



5145 



5150 



3155 



5160 



5165 



RESULTCODE TrsmferBiiffert BYTE* j,aof # 

*»» ..aBytes m i, 

const char- .pMcoLabel • 0 

B °OL .UQuery « 0, 

/• BOOL .UB^Ckifig - 1 ); 



USAGE: Transfer buffer to or from 
PARAM: _pBuf 

.nBytes 

_pMcoL*bci 

.UQucry 

_liBIockjng 

RETURN: Failure 
Success 



TtmatfOut 

Raqurtrnmifd 

NocSupponcd 

MuttBeOpened 

Disabled 

lnUse 

Memory AllocError 

ftecourceAllocEnor 

lnenulEnur 

InvaiidDaiaType 

InvaJidObject 

tmraiidParam 

CaUMustBeConnected 



rCfn ° lC Iaoon - •tependmg on the sigiu) rype for the object. 
Ptr to data buffer to transfer. 
Number of bytes to transfer. 

Ptr to iabcJ for media cert data object, or null to indicate default. 
■True if caU is to query sub-system for operaoon capability. 

non^L^* WOCkWg * W,U ™ Kttim ^ or false if 

non-olocking & rcoirns immediately as 'pending*. 
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5170 



3175 



5180 



5185 



5190 



3195 



5200 



RESULTCODE TramferObject( MCO XFEROBJ XltrObJ, 
XferObjecf IpXferObj. 
coaa char- jpMCO Label - 0. 
BOOL bQoery « 0. 

BOOL um^b^ c « i ); 

/* 

USAGE: Transfer dia object to or from remote naaon. depending on the signal type for the object. 



PARAM: _XferObj 

_pXferObjccs 
_pMcoLabcJ 
JsQoery 
_UB locking 



RETURN: Failure 
Success 
Pending 
TiaedOut 



No 

NotSupponed 
MoafieOpened 



InUse 

Memory AilocError 

ReaourceAUocfirror 

IfttBrnalEfTOT 

Invalid DstaType 

InvalidObject 

InvaiidParini 

^*iti M miBfCon r*TTT r ri 



...Type of object to transfer. 

...Pit id the object' t dexenptor object containing specific uiformaaon. 

...Pit to label for media Ctrl data object, or null to indicate default. 

...True if call is to query sub-system for operation capability. 

...True if call is blocking St will not return until complete, or false if 
non-blocking Sl returns inuncdiately as "pending". 
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5205 V*..... ............ 

TERMINAL SERVICE CONTROL 
-.---.*-..--...--..-•/ 

RE5ULTCODE ToTernmaU char" j)Fmt, .„); 
5210 /• 



5215 



5230 



USAGE: Wnte data to the VCO ccmunaJ OUTPUT port opaonaily using formic urmg and variable 
number of arfumenis. 

PARAM: _pFmt ...Pit to format sinng. 

- Variable number of text and data args. 



RETURN: Failure 
Sums 

5220 RequestDcnted 



InUse 

InvaiidDaaType 
bwalidParon 

5225 •/ 



RE5ULTCODE TToTermtnaK char* _jtFmt, 

void* jiArfUst ); 

/* 

USAGE: Wnttdaato the VCO terminal OUTPUT port opaonaily using format string and h» of pas 



PARAM: j>Ftm ...Porto format srnng. 

5235 j>Ai»Li* ...Ptx to h« of ptr* to irg wrings. 

RETURN: Failure 
Success 
RequestDenied 
5240 Disabled 

InUse 

InvalidDataType 
LnvatidParam 

•/ 

5245 
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5230 



RESULTCODE FromTcnamalf char* jjFtal* ...); 
/• 

USAGE: Write dao to the VCO terminal INPUT pon (VCO command interpreter! otraomlly astng 
format smug and list of ptrs to arguments. 

PARAM: __pFroi ...Ptr to format strtng. 

.-• Variable number of text and data srgs. 

5235 RETURN: Failure 

Success 
Reqne t tD cnie d 
Disabled 
InUse 

5260 InvaiidDaaTypc 

InvaiidParam 

*/ 

RESULTCODE vFromTcrminaK char* j>Ftau, 
5263 void* jiArgLul ); 

/• 

USAGE: Write data id the VCO termmai INPUT pon (VCO command interpreter) optionally using 
format string and list of ptrs to arguments. 

5270 PARAM: jiFtnt ...Per to format smog. 

j>AigList ...Ptrtoliw of ptrs to irg smugs. 

RETURN: Failure 
5275 Success 

Retfuctt Denied 

Disabled 

InUae 

lnvaltdDataType 
5230 InvalidParam 
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52S5 



5300 



5330 



5323 



5330 



5335 



RESULTCODE AttachTermToNotiftert HNOTIFXER _hNotifler ); 

USAGE: Atacto signal as VCO terminal output device in order to direct terminal OUTPUT doit text 
stream to the associated Norifter Receiver Object (NRO). 

PARAM: JiNoufter ...Handle to signal to attach 



»90 RETURN: Failure 



5295 



RcvsucstDcnicd 

Disabled 

InUxe 

InvalidNonfier 



RESULTCODE AuacuTenaToFUe( char* _pFUcspec, 

BOOL _UAppcnd - 0 ); 



USAGE: Attach file as VCO terminal output device m order to direct terminal output pon text stream 
to a specific file or file system device. 

5305 PARAM: jjRUspec ...Ptr to file specification of file to attach. 

-tsAppcnd Troe ^ new text to be appended to current stream position: false if 

stream position to be reset at ome of aoachement. 

3310 RETURN: Failure 

Success 



RequeatOented 
Disahied 

3315 bUJse 

iBvalidDaaTypc 



RESULTCODE AttachTermToStreanK strum* _pSu*mm* 

/# BOOL .UAppend - 0 ); 

USAGE: Attach system data stream as VCO terminal output device in order to direct terminal output 
port teat stream to specific data saeam entity. 

PARAM: _pStream ...Ptr to stream to asacfa. 

.UAppend ...True if new text to be appended to current stream position: false if 

stream position to be reset at time of attachment. 

RETURN: Failure 
Success 
Redundant 
RequestDenied 
Disabled 
InvalidDataType 
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RESULTCODE AlUchTermToMctrf HMCO _hMco. 

BOOL ~UAppend ■ 0 ) : 

5340 /• 

USAGE: Attach media ctrt object as VCO terminal output device m order to direct terminal output 
port text stream to media ctrl object supporting data transfers. 



5345 



5360 



PAJRAM: hMco ...Handle to media ctrt object to attach. 

UAppcnd ...True tf new teat to be appended to current stream poxtnon: false if 

stream postson to be reset it nme of attachment. 



RETURN: Failure 
5350 Success 

Redundant 
ReojuestDenjed 
Disabled 
UwalidDataType 

3355 •/ 

RESULTCODE DeucbTermF rom{ TERMODEV OutputDe* ); 



USAGE: Remove previously i rachrd signal, file, or daa stream from the terminal output port. 
PAJtAM: _OuiputDev ...Tcrminai output device from which to dexach terminal output. 



RETURN: Failure 
5365 Redundant 



5370 



Disabled 
InUse 

InvaltdDataType 
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------ 

SYSTEM INFORMATION CONTROL 
5375 _--*/ 

BOOL IsResdyO; 
/• 

5380 USACE: RenTO <IUe ,f VC ° U rcady inxooJ call io remote staoon or mulopmm conrrol «mt. 

PARAM: none 

RETURN: Tnie 
False 

5385 •/ 

BOOL IsCaUSctapO; 



5390 



5400 



5410 



5420 



5430 



5435 



USAGE: Returns true while call is semng up. but not connected. 
PARAM: none 



RETURN: True 
False 

5395 •/ 



BOOL IsCallO; 

USAGE: Returns out white call is fully connected to 
PARAM: none 



RETURN: True 
False 

5405 •/ 

BOOL IsMuhiCaUO; 
/• 



USAGE: Returns true while connected to more than one remote station or mulopoim control i 
PARAM: none 



RETURN: True 
False 

5415 -/ 

BOOL ZsRemoteVcoO; 



USAGE: Returns cue if remote saoon is a mulnpouu comrol unit. 
PARAM: none 



RETURN: True 
False 

5425 •/ 



BOOL IsRamotcAOacfacdO; 
/• 

USAGE: Returns true if remote scaoon VCO command and/or event stream is accessible to local station. 
PARAM: none 
RETURN: True or False 
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5450 



5470 



3475 



BOOL IsMu 

USAGE: Returns true tf thts VCO U ruiuuag with more thin one trainee. 



5440 PA RAM: 

RETURN: True or False 



5445 DEVXCEPARAM& GctDenceParanO; 

/• 



USAGE: Reurm reference to sane buffer conatmng copy of VCO device parameters. 
PA RAM: none 

RETURN: Reference to copy of VCO device parameter block 



CONFIGPARAM& GetCoaftgPanmO; 
5455 /• 

USAGE: Returns reference to sane buffer conatmng copy of VCO coafig parameters. 
PARAM: none 

5460 RETURN: Reference to copy of VCO configuraoon parameter block 

•/ 

CALLPARAM& GetCallPanmO; 
/• 

5465 USAGE: Reainu reference to sane buffer containing copy of VCO call parameters. 

PARAM: none 

RETURN: Reference to copy of VCO call parameter block 

•/ 

PROTOCOLPARAMA GeiPracocoiPsntmO; 
/* 

USAGE: Returns reference to sane buffer co naming copy of VCO protocol parameters. 
PARAM: none 

RETURN: Reference to VCO protocol parameter block 

•/ 

5480 

CONTROLPAKAM& GdCo&trolPmnO; 
/• 

USAGE: Reoims reference to sabc buffer coitauning copy of VCO control contest parameters. 
5485 PARAM: none 

RETURN: Reference to VCO control context parameter block 

•/ 

5490 MONTTORPAKAMAi GciMooitorPinmO; 

USAGE: Returns reference to sane buffer containing copy of VCO monitor context parameters. 
PARAM: none 



5495 



RETURN: Reference to VCO monitor context parameter block 
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VC OP ARAM 4 GctVeoPamnO; 
5500 /• 

USAGE: Returns reference to staoc buffer containing copy of all VCO parameters. 
PARAM: none 

5505 RETURN: Reference co VCO system information parameter block 



5510 



5515 



5520 



5525 



5530 



5535 



5540 



5550 



5555 



5560 



MCOPARAM& GetMcoParamf MCO TYPE McoType ); 

USAGE: Returns reference to suae buffer comatnmg copy of media Ctrl parameter Mock. 

PARAM: .McoType -Type of media ctri ob^ct 

R£TURN Rcfcrencc to mcda «'» P^metcr block for specified media art object 

M COP ARAM & GetMcoParamf HMCO hMco )• 

USAGE; Returns reference to staoc buffer containing copy of media Ctrl parameter block. 

PARAM: _hMco .„Ha«Ue to media cut object 

RETURN: FUfcrencc «» media «rt object parameter block for specified medu coi obrect 

VTDEOSIZE GetVideoSdei MCO.SIGNALTYPE .SigType - SignaiDrt >; 

USAGE: Resin video frame sue for default video object of specified signal type. 
PARAM: _SigType ...Video signal to examine for size 

RETURN: Enumerated video frame size value 

•/ 

AUDIOQUAUTY GtlAudioQuality< MCO.SIGNALTYPE .SlgType - SignaJDst ); 
USAGE: Return quality of default audio object of specified signal type. 
PARAM: _SigType ...Audio signal to examine for quality 

RETURN: Enumerated audio quality value 



char* GcLH22lModeLabcl< BASCODE Mode); 
3543 ««» *»«r* GclH221CapLabd( BASCODE Cap >• 

cooat char- GctltovicftStauUfcclf DEVICESTATE DevsccState )• 
costs* cnar* Gc tRm n T oriil ■bcJ( RESULTCODE ResuilCode 
cooat char" GetEvtntLabeK EVENT Event ); 

char* C H l J itf . St«H , a beJ( LINE5TATE LiacScate )• 
ehar* GetOdiSlataLabelf CA1XSTATE ~ CaUState >; 
char* GtiMtdMaCsttovfTokeni ahei< uu MediaCtrlTokco »• 
char* GetMcoLabelf HMCO bMco >; " 

GelMcoUbeK MCO TYPE .McoType ); 



coast char* GctMuWCallOpLabell MULTICAXXOP* MuWCeUOo J* 
coast char* Gc iSutinn l abeif BOOL _iaRctsoteStatloo - 0 ); 

USAGE: Return ptr to text label specified state or constant item . 

PARAM: The specified sate or constant 

RETURN: Ptr to constant stnng if argument valid, else null 
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HMCO GctMcoHandlef const char* _pMcoLabd ); 
5365 /• 

USAGE: Return handle to media Ctrl object specified by its label. 
PARAM: _pMcoi-abel ...Pit to label id media cm object label. 

3570 RETURN: Handle co media art object specified by the label, else mill if no such media Ctrl object round. 

HMCO G*tMcoHandle< MCOJTYPE McoType ); 
/• 

3575 USAGE: Re aim handle to media Ctrl object specified by its type. 

PARAM: _McoType ...Media coi object type. 

RETURN: Handle to media art object specified by the type, else null if no such media cut object found 

5580 •/ 

RESULTCODE UstDericePsnmO; 

RE5ULTCODE UtfConits^PanmO; 

RESULTCODE ListCaHParamO; 
53BS RESULTCODE UstPretocolParamO; 

RESULTCODE UatMoaeCapsXRefsO; 

RESULTCODE UstMCOBiadincsO; 

RESULTCODE UstMCOsO; 

RESULTCODE ListNotifleraO; 
5590 RESULTCODE I IttCommandsQ; 

RESULTCODE UstTcn&uulOtstpottO; 

RESULTCODE LMConlercesO; 

RESULTCODE UstCoancctieiiCansO; 

RESULTCODE UstMuUCaUStatesO; 
55% /• 

USAGE: Output formatted text listing for specified parameter groups 

PARAM: none 

3600 RETURN: Famire 

Su 



S610 



5625 



5630 



RESULTCODE UslMcoCaps* MCO TYPE McoType. 
3605 MCO' SLI 11N G 'Settlnc ); 

/• 

USAGE: Output formaoed teat listing of capaotlutes for specified default media Ctrl object. 

PARAM: McoType ...Specific media Ctrl object to address 

. . .Audto-vtoeo-data semng constant specifying requested 
desired from object. 



RETURN: Failure 
5615 Success 

Invalid Object 
tnvsJidSening 

•/ 

5620 RESULTCODE Usl5lationCaps( STATION" _pSt*tton - 0 ); 

/• 

USAGE: Output formatted teat lisnng of H. 221 capabilities for specified staoon. 



PARAM : j&Sa&on ...Pit to station descriptor (0 reurtu caps for local station). 



RETURN: Failure 
Success 
InvaiidSntton 
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5640 



5645 



56SS 



5660 



5670 



3675 



5680 



56K5 



VIRTUAL CONNECTION OBJECT CONTROL 



5633 RESULTCODE Enable Vc* BOOL .IsEambted - 1 ); 

USAGE: Set VCO enable fUg to true or false to change accessibility of VCO. 
PARAM JsEaabted ...True if VCO to be enabled: false to disable. 



RETURN: Failure 



RESULTCODE SetVeoEaeeptModef EXCEPTMODE .Mode - EaeptModeUser >; 
USAGE; Set the current VCO eacepuon handling modal uy. 
3650 PARAM: .Mode ...Exception handling mode desired. 



RETURN: Faihire 
Success 
Redundant 
RequestDcaied 
NotSupponed 

*/ 



RESULTCODE SetVcoTraceMod* TRACEMODE .Mode - 0 ); 
USAGE: Set the current VCO trace output modality. 
PARAM: .Mode . . .Trice output mode desired. 

3665 RETURN: Failure 



RequestDenied 
NotSupponed 

•/ 

RESULTCODE ExiaokMuUiCallOpsI BOOL UEnabled » I )- 

USAGE: Enabteor disable the muhipoim call control operaooru. Tha operaoon can only enable 
mutopotm call control operations if they are supported by the VCO ^ nmrn 

PARAM: _lsEnbtcd ...True if multipoint control operations to be enabled: false t. 

RETURN: Failure 



RcquesiDenied 

NotSupponed 

MtmBeOpened 

Disabled 

InternalError 



WO 98/09213 



PCT/US97/150I8 



-201- 



RESULTCODE EnabltDispatehert BOOL _ Is Enabled ■ 1 >; 
USAGE: Enable or disable the VCO dispatcher. 

PARAM: JsEiatted ...True if VCO dispatcher operating; false if not. 

5«3 RETURN: Failure 

Success 
Redundant 
InUsc 

TimerFaiiure 

5700 •/ 

RESULTCODE Queu*£vent< EVENT Id. 

DWORD 'hnml, 
m€ WORD *P.«m2. 

5705 STATION- ^SUtion - 0 ); 

/• 

USAGE: Insert event into the event queue. 



5710 



5715 



5720 



5723 



PARAM: Jd ...Event identifier. 

_Param t . . .First event parameter. 

_Ptnm2 ...Second event parameter. 

_pSotbon ...por b> station descriptor (null indicates local itaaom. 
RETURN: Failure 



QucucFull 
MesnoryAliocError 
InvaiidStauon 
lnvmlidDaciType 
InvaUdOperaoon 

•/ 

RESULTCODE 5etDispateherRate( int Msec ~ DefanlU>ispaictterRate ); 

USAGE: Set (he rate at which events are dispatched from the event queue 

3730 PARAM: .Msec ...Dispatch rate in milliseconds. 

RETURN: Failure 

RequestDentpd 

5735 TtmcrFaihire 

InvaiidParam 

•/ 
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5740 



5743 



5750 



5755 



5760 



5745 



5770 



5775 



5780 



5785 



5790 



5795 



RESULTCODE Up«UteCapsLut< BASCODE Cap, 

ZpCapLabtl. 
BOOL ^IsNewC.p - l ). 

USAGE: Add or remove capability to/from local capability list. 



Capability constant. 
-.Ptr to label for capability. 

.True if new capi id add to li«: false if cap to remove 



PARAM: _Cap 

j)CapUbel 

JsNewCaps 

RETURN: Failure 
Success 
Redundant 
R rquei tDenied 
InvalidDasaType 
InvaltdCapabiltty 
InvslidParam 



RESULTCODE UpdateModeCapaXRen XREF* jJOUf. 

BOOL _UN«wXRcf m i ); 

USAGE: Add or remove mode-caps erosi-reference co/from local list. 

PARAM: J>XRef - Ptr to mode-caps cnm-rcfcrence record. 

_IsNewXRef ...True if new record to add: false if record to remove. 

RETURN: Failure 
Success 



RcqucsiDenied 

InvalidOauType 

InvaltdCapabiltty 

•/ 

RESULTCODE EouConirolf EMUCONTROLOP Op, 

fm STATION* ^Station « o ); 

USAGE: Prescm emulation controj operation to a VCO. 

PARAM: _Op ...Emulation conrrol operation. 

-P Sttnon •• ptr to *»non descriptor (null indicates local staboa). 

RETURN: Failure 



RcqpfttrVmed 

NocSupponed 

UttctrsuError 

InvaiidOperanon 

InvajidOperaoonNow 

lnvaudSuuion 
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5800 



5S25 



5850 



5855 



RESULTCODE A UachTo Remote Veof BOOL JsMeoiterOnly » 1. 

BOOL 'isBtocajng - 1 >; 



USAGE: G^i^uto the command and/or e rem scream of the remote moon. TO, acoon » oniy 
possible if the remote station u running a VCO for its mulumedi. connection services. 

5805 PARAM: JsMorutorOnly .True if request is only to monitor me remote VCO's event stream. 

and not us command scream (for the purpose of mattering u). 

.lsBlockmg ...True if call u blocking A will not return unoi complete, or false if 

3810 RETURN; Failure nonlocking A returns tmmedarely as -pending-. 

S 



. . Pending 
TtmedOut 
Rrmmrtini 

*8tS RequMfDcmed 

NotSuppoffted 
Process Terminated 
MustBeOpened 



SOO InUse 

IntenuUError 



UndcfmedResuit 
CallMusiBeConnected 



RESULTCODE DeUchFrtmiRemoceVco< BOOL _UBlocking * 1 ); 

USAGE: Discard access gained to cornmand and event stream of remote itanon. 

5830 PARAM: JsBlocking ...True if call is blocking & will not return until complete, or false if 

RETURN: Failure nonlocking A returns mtnsedoaxely as -pending-. 

Success 
Pending 

5835 TisncdOut 



RequcstOecued 
NotSupported 
ProccssTe rmmated 
Capable 



MustBeOpened 
InternaiError 
Tuner Failure 

3843 UndcfmcdResult 

CaOMustBeConnected 



RESULTCODE SetVcoConirolMode< DWORD _ModeFlags - Master ,; 

USAGE: Set the mode of VCO control so thai call* m . , 

VCO as corrfigurod member functions dwe die local or the remote 

PARAM: .ModeFUgs ...VCO control mode flags selected from < CONTROLMODE > 

RETURN: Failure 



Redundant 
RequestDenied 
5860 ImemalError 

tnvaltdOpe ration 

InvaltdOperauonNow 

CallMustBeConnectcd 

•/ 

5865 
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5870 



5875 



5880 



5890 



RESULTCODE SciVcoMomtorMod* DWORD _ModeFlags « MonModeLocai ); 

USAGE: Set the mode of VCO monitonrw so that t**. «™ - 

from the loci. ftniaJT^^^^, ""^ — ™ *™ -» VCO cmana*, 

PARAM: .ModeRag, ...VCO monaor mode flag, seiected from < MONTTORMODE > 

RETURN: Failure 

Success 

Redundant 

RequestDeiued 

ImernaiError 

InvaJidOperuion 

Imrai tdOperauonNow 

CattMustBeConneaed 



RESULTCODE SctSutioaLabeH char* jiUbtl, 
5885 ^ 

USAGE: 5ci label for the local station. 



PARAM: j>Ubel ..Pir to .anon label. 



RETURN: Faihire 
fttcrrti 

InvalidDataType 
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5893 



ALL MEMBERS BELOW ARE TO BE ACCESSED ONLY FOR THE IMPirMFJJTAXTniu """" 
OF THE ABOYX-DETOED PUBUC MEMBER FUNcS Xt JSSmSS^SS CONTROL 
INTERFACE COMPONENT OF EACH VIRTUAL COW«(nf<^iSci CO ™*- 

5900 .» . ^t^° T AVAlLABLE T ° CLIENT APPLICATIONS. 

pnvite: 

rypedef eoum { 

5905 OSS' " lnV ° kC 0EM audU> «* con *~« 

^S!' // Invoke OEM v«lco setup component 

S^ 0 ** " l«vokc OEM image setup component 

» invoke OEM data setup component 

Upda^UpsUxt. // Add or remove device capability 

5910 D^hptI^S~Iu,« " PcrforTTJ dev,ce °P«™n°n$ to connect to remote VCO 

SSS^ " Perform dC¥tce *!»»«« to deocn from remote VCO 

vendorSpecutcOp. // Vendor-specific device control openoons 

5915 lOCorarolOpEnd 

} IOCONTROLOP: 



PURE VIRTUAL DEVICE CONTROL MEMBERS 

5920 

virtual RE5ULTCODE DevOpeut BOOL _b Bloc king ~ I) « 0; 



SOM USAGE: Open e«aoauated devicej. load and iruoaltze OEM device comroJ software and MCI device 

drivers: prepare VCO to place outgoing, or receive incoming caU. 

PARAM: JsBiocking ...True if call is blocking * will not mum unoJ complete, or false if 

non-Mocking & returns immediately as 'pending". 

5930 RETURN; Failure 



TimcdOui 
Memory Alloc Error 
Resource Alloc Error 
Inirmai Error 
Timerratlure 
InvaiidDcvicc Return 

•/ 

5940 

virtual RESULTCODE DevClosef BOOL _ Is Blocking = 1> » 0; 

USAGE: Close encapsulated devKes. unload OEM device control software and drivers: snutdowa all 
^ systems related to establishing calls. 

PARAM: _lsBkxkmg ...True if call is blocking * will not return until complete, or false tf 

non-blocking 4t re turns immediately as 'pending*. 

RETURN: Failure 

5950 



MustBeOpened 
Memo ryAiloc Error 
Resource Alloc Error 
uuernaiError 

5955 •/ 
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5960 



5965 



5970 



5975 



5980 



nnual RESULTCODE D«vConnm( CALLPARAM& CaUParam, 

STATION* IpSuboa. 
/# BOOL ^Blocking - 1 ) 

USAGE: Connect to remote lunon or mulnpotm control unit. 



0; 



PARAM: CallParara 
jxSttnon 
.^Blocking 

RETURN: Failure 
Success 



Pending 
TimedOui 
MuuBeOpened 
InUse 

Memory Alloc Error 

Resource AilocError 

lnienniError 

InvalidStaoon 

InvalidDaaType 

LineConnectFailed 

LineliBusy 



...Reference to a VCO call parameter record. 
• Prx to remote sanon descriptor to whicn connect is desired. 

ool^^x b,OCk,ng * WUI "* reium ™»* campicte. or false if 
t»on-btocking & returns tmmedately as 'pending-. 



5985 



5990 



5995 



6000 



6005 



6010 



6015 



6020 



virtual RESULTCODE DerMultiCooaectl MULTICALLOP Op. 

CALLPARAM& "CaflPinm, 

STATION- j>Scation - 0 

j"*^ .HQuery - 0.' 

/• BOOL IsBtockinc • 1 > * 0; 

USAGE: Implement multipoint control operation while connected to multipoint control unit. 



PARAM: jOp 

_CallParam 
_pSttuon 
_UQu«ry 
_lsSlocking 

RETURN: Failure 
Success 



TtmedOut 



NoiSupponed 

MustBeOpened 

InUae 

Memory Alloc Error 

Resource Alloc Error 

uvemdError 

InvalidSaoon 

InvaiidDaaType 

InvalidOperaoon 

tnvalidOperanonNow 

CiilMustBeConnectcd 

NoGaJIForUneAdd 



.-Mulopoiru control operanon. 

...Reference to a VCO call parameter record. 

..Pip to station descriptor lor selected operation. 

..True if call is to query sub-system for operaoon capability. 

^True if call is blocking A will not return until complete, or false if 
non-Mocking & returns immediately as 'pending'. 
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virtual RESULTCODE Dev Disconnect! int oJLine * 0. 

BOOL JsBIocking - 1 ) - 0; 

/• 

USAGE: Disconnect one or more tines connected to remote saaon or multipoint control unit. 



6030 



6035 



PARAM: _nUne ...Number of line to disconnect; null disconnects ill lines 

_IsB locking ...True if call is blocking & will tuk return unnl complete, or false if 

non-blocking & returns immediately as 'pending". 

RETURN: Failure 



Pending 
TimcdOirt 
MustBeOpcned 
InUse 

6040 MemoryAUocError 

Re sou rceAl toe Error 
Interna I Error 
InvalidLine 
CallMustBeConnecced 

6045 •/ 

virtual RESULTCODE Dev Answer! CALLPARAM& CaUParam, 

ta» aline > = 0; 

/• 

6050 USAGE: Answer incoming call from remote station. 

PARAM: CaUParam ...Reference to a VCO call parameter record. 

_ni-xne ...Number of line to disconnect: null disconnects all lines. 

RETURN: Failure 



6055 



MustBeOpened 
IsUse 

6060 Memory AllocError 

ResnurceAUocError 
IncernalError 
InvalidDaciType 
InvalidLme 

6065 InvalidOp eranon Now 

lincConnectFailcd 



virtual RESULTCODE DevAbortO - 0; 
6070 /• 



USAGE: Abort entire connection, or connecoon in progress, to remote stanoq or mulapoinx cannot "«« 
PARAM: none 



6075 RETURN: Failure 



Mttst BrO p coc d 
laUse 

6080 MemoryAUocError 

RcsourccAilocBrror 
lnternalError 
CaluUustficConnccted 

•/ 

6085 
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6090 



6105 



6130 



6135 



virtual RESULTCODE D«vGetCa!llirfo< CA1XPARAM& _CallPanm i - 0; 

USAGE: Get infornution for call, or for partially connected call. Can be used white 
establishing to monitor call progress. 

PARAM; .CaitPaiam ...Reference to a VCO call parameter record 

RETURN: Failure 
Success 



6095 TimedOui 

MusiBeOpened 
MustfieClmed 
InUse 

Memory AltocError 

6100 RejouneAUocError 

lnternalEnor 
InvalidDaaTypc 
UneNotConnccted 
UnelsBury 
DisconneciAequesx 

•/ 



nrtuml RESULTCODE DevMediaControK MCO TYPE Me^Type, 

611Q MCO "SETTING 'Setting, 

DWORD Pam - 0, 

BOOL "isQuery - 0. 

/# BOOL .IsUoduac « l) - 0; 

6U3 USAGE; implement media Ctrl control scamg by making calls to device control wftwire 

layera and MCI device drivers. 

PARAM: (same as MtdiaConrolk 

RETURN: Failure 

6120 



6125 



TimedOut 
RequeitD t tucd 
MustBeOpened 
InUse 

Memory AilocError 

ResourceAHoc Error 

tntcRtalError 

TtmerFauurc 

UndefinedResuit 

InvaiidDiaType 

InvalidOpenaon 

InvalidOperaoonNow 

InvatidObject 

InvalidSeiQAg 

InvalidParam 
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vfrtual RESULTCODE DevEmuCooiroK EMtiCONTROLOP On > « 0: 
6140 /• - K 

USAGE; Implement crraUaxion control openoon for this VCO 

PAJLAM: (tame u EmuComrol) 

6145 RETURN: Failure 

Success 



ReojucitDetvcd 
MustBcOpcoed 
6130 Memory AUocError 

Resource AJloc Error 
LmeroalError 
Invalid Operation 
InvaladOperuionNow 

6133 •/ 
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6160 



6165 



6170 



6175 



6180 



61&5 



6190 



6193 



6200 



6205 



6210 



6215 



6220 



*mttti RESULTCODE DcvXmtOaU( BYTE* j>Bm\ 

tat .ofiytcf m i. 
HMCO hMeo • 0 
BOOL JsQurrv-o, 
BOOL .bBtocteng • i ) • oj 

USAGE: Transmit daca buffer to remote sut^on. for a specific data object. 



PARAM: j)Buf 
_nBytes 



.UQuery 
IsB locking 



RETURN: Failure 
Success 
TimedOut 
NocSupponed 
MustBeOpcned 
InUse 

MeraoryAItocError 

ResourccAitocError 

Inrernai Error 

InvelidDataTypc 

ln¥iiadOb)ect 

ImnJidPinn 

CaHMusiBcConnected 

•/ 

virtual RESULTCODE DevRcrDauf BYTE* 

tat 

HMCO 
BOOL 
BOOL 



•Pit to buffer containing data. 
■Number of bytes to transmit. 

-Handle to data object to use for data transfer: null indicates default. 

■True if cail is to query sub-system for operation capability. 

^rue if call i, blocking A will not reotrn until complete, or false if 
wwHriocking & returns immediately as ■pending \ 



_pBul\ 
.ofljrtes « 1 

_OMcO m 0, 

_lsQuery - 0, 
.IsBlockuag • 1 ) m 0; 



USAGE: Post request to rece.ve data buffer from remote stanon. for a specific data ob.ect. 



PARAM; j>Buf 
_nBytes 
JiMco 
_lsQuery 



RETURN: Failure 
Success 
TimedOut 
WotS up po rie d 
MustBcOpened 
InUse 

Memory AilocError 

ResiurceAllocError 

imcnxalError 

lnvaiidOataType 

lnvalidObjeet 

lnvaltdParam 

CallMuscBeCormected 



.Pit to buffer conauung data. 
.Number of bytes to transmit. 

•Handle to data object to me for daa transfer: null indicates default. 
...True if cail is to query sub-system for operation capability. 

r^JL^* WOCkmg * Wd ' 001 rcmni 0001 cora * Ctt - « " 
non-mocking A. returns immediately as 'pending'. 
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6230 



6225 

nrtuai RESULTCODE DerSetModesf BASCODE" jiModeUst. 

uu .oModes « 1 >; 

/• 

USAGE: Anempt to set H.221 device modes for call in progress. 

PARAM _pModeUsx ...Pu to list (amy) of H.221 mode coruana co set. 

nModes . . .Number of modes in list. 

6235 RETURN: Failure 

Success 

TimedOui 

RequegPewed 

MustficOpcned 
6240 --- Memory AllocError 

Resource AlIocError 

IxiicttuI Error 

InvaiidDauTypc 

InvmlidMode 

6245 InvsiidPanro 

CallMusiBeConiiected 

•/ 

virtual RESULTCODE DevSendCaps< BASCODE* _pCapUxt, 
6250 lot _nCaps » I ) - 0; 

/• 

USAGE: Transmit the specified capability set co the remote station. 



6255 



PARAM: (same as SendCaps) 



RETURN: Failure 

Sffl TTt f 

TusedOut 
RemtestDeiued 

6260 MustBeOpcoed 

Memory Alloc Error 
ResourceAllocEnor 
IncemalEfTDr 
InvaltdDataType 

6265 tavalttCapabtiuy 

tnvalidPanun 
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*rtual const char* DevGetModeLahelf BA5CODE Mode ) - 0- 
6Z70 f% - * 

USAGE: Get text label for specified H.22J mode. 



6275 



6290 



6295 



6310 



6315 



6320 



PARAM: .Mode ...HJ2I mode constant. 

RETURN: Pir to constant character string if argument valid, else null 



virtual const char» DevGeiCapLabeK BASCODE Can > « 0- 
/» - 

USAGE: Get text label for specified H.221 capability. 

PARAM: .Cap ...H.221 capability constant. 

RETURN: Ptr to constant string if argnmcm valid, else null 

OZIU •/ 

virtual MCOPARAM& DevG«tMco< HMCO hMco ) - 0; 

USAGE: Return reference to static buffer containing copy of media «rl object parameter block 
PARAM: .hMco ...Handle to media ctrt object. 

m/ R£TURN: ^e«nce to copy of media ctrt object parameter block for specified media ctrt object 

virtual HMCO DevCetMcoHaadk* const char* _pMcoL*bel > m 0; 
USAGE: Ream handle to media Ctrl object specified by its label 
"00 PARAM: j>McoLabeJ -Ptr to label to media Ctrl object label. 

^ RETURN: Handle to media Ctrl object specified by the bbcl. else null if no such media cat object found. 

6305 virtual HMCO DevGetMcoHandlef MCO TYPE JUcoType > = 0; 

USAGE: Return handle to media col object specified by its type. 
PARAM: _McoTypc ...Media ctrt object type. 

RETURN: Handle to media ctrt object specified by the type, else null if no such media Ctrl object found. 



virtual RESULTCODE DevSetDefaullMco< MCO TYPE .McoType. 

/m eanatehar* ^PMcoLahcl ) - 0; 

USAGE: Set the VCO*s default media ctrt object for the specified object type. 

PARAM: _McoType ...Type of media ctrt object to which the default will be set. 

_pMcoLabci . ..Pit m label for tncdia ctrl object to set as default. 



RETURN: Failure 
Success 

6323 Redundant 

NotSupported 
MiutBeOpcned 



InUse 

6330 bttCTtiaJError 

InvalidDataTypc 
InvalidObject 
Invalid Scmng 

•/ 

6335 
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6340 



virtual RESULTCODE Dev$eiDefaultMco< M CO TYPE McoTypc, 

HMCO ~oMco > a 0; 

/• 

USAGE: Set the VCO'i default media Ctrl object for the specified object type. 

PAftAM: _McoType . .Type of media Ctrl object to which default media Ctrl object will be set. 

JiMco . . .Handle of media Ctrl object to sci as default. 



6W5 RETURN: Failure 

Success 



NocSupponed 
MustBeOpened 
6350 Disabled 

laUse 

InteroalError 

InvaltdDataType 

InvalidObject 

6355 InvaiidSemng 



virtual RESULTCODE DevSetTinieout( DWORD Msec ) ■ 0; 
6360 USAGE: Set connect omeout for network interface una. 



PAJLAM: _Msec ...Timeout value in milliseconds. 

RETURN: Failure 
6365 Success 

TimedOui 
ReoucstDcmcd 
MttitBcOpened 
Memory Alloc Ei ror 

6370 ReatwrccAllocError 

taternalError 
Timerranurc 
InvaiidDataType 
uTvalidParam 

6375 •/ 

virtual RESULTCODE DevVenfyBandwuHhf BASCODE AudioMode, 

BASCODE ~DauMode ) « 0; 

/■ 

* 380 USAGE: Verify thai connection has sufficient bandwidth for specified audio-data mode comrjinaoon. 

with respect to die current video mode (if applicable). 

PARAM: AudioMode ...H.221 audio mode. 

63S5 DaaMode ..3iJ2\ data mode. 

RETURN : TimedOut 
Capable 



6390 MustBeOpened 

InUae 

Memory AJ I oc Error 
Resource Alloc Error 
IntetmlError 

6395 InvatidMode 

CallMustBeCon 
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6400 



6405 



6410 



6415 



6420 



6423 



6430 



6435 



6440 



*rttt»! RESULTCODE DevIOComroK lOCOmTROLOP Op, 

DWORD "Pas^mi . 0 

DWORD ~P»r«ni2 - o! 

BOOL ~lsQuny - 0. 

BOOL .liBiocking - 1 > « 0; 

USAGE: Implement input/output device control operation by miking calls co devtce control mfn*.~ 
^Tare"^^^ 

co^n, member funcoon * pZZ^ .lt^^Z^^" 



PARAM: _Op 

.Puiml 
_Puam2 
_UQuery 
JsBlockmg 



RETURN: FaUure 
Success 



..input/output device concrai operation requeued. 

M provtdes parameter necesary to fully specify request. 

...If required, provides parameter necessary co fully specify request 

• Tna query sub-system for operation capability. 

...Troe if call u blocking & will not return until complete, or false if 
non-blocking & returns immediately as "pending". 



TimedOut 



MuszBeOpened 



Memory AllocError 

ReaoorceAllocError 

InttnulEtror 

TtracrFaiturc 

UndefinedRexuit 

ImtlidDaaType 

Invalid Ope raoon 

Invalid Ope raoonNow 

InvalidPinm 

...Others according co imptcme 



i requiremena 
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BIT-RATE ALLOCATION SIGNAL HEADER FILE 



6445 



6450 



6455 



6460 



SAMPLE HEADER FILE 
for 

H.221 BIT-RATE ALLOCATION SIGNALS 
istd to indicate 
DEVICE MODES AND CAPABILITIES 

ABSTRACT 

This source module contains header information that will pnmde a devtce -independent eprexemation of btt-rat* allocation sitml 
commands (BAS codes) used co indicate device modes and capabilities according to the H.320 (specifically H in 
Recommendation. These lists ire intended for ilhistaove purposes, and are incomplete. An implementation of a VMCS would 'need 
to define a complete list, and men preserve the exact numerical identity of these constants for all impicmenomom miended for 
interoperatany within the same operating environment. virtuaJtzauon routines in the VL (of VCO impierneimmonsi 
these devicc-tndependcni versions of H.221 modes and capabilities into the actual BAS codes formats specified bv the 
recommendaoon for line transmission. 7 

(SOURCE FILE: BASCODES.H) 



6465 



6470 



PROGRAMMING NOTES 
This module contains only C+ + source code and structured comments using the " // ' 
(he standard C comment notation using "/••/*). 



notaoon to denote comments (in »lriirmn 



/•« 



BIT- RATE ALLOCATION SIGNALS TO INDICATE DEVICE 
CAPABILITIES (DEVICE MODE CAPABILITIES) 



// TRANSFER RATE CAPABILITIES 
BASCODE CapTnnsferR*t«64 

6475 BASCODE CapTrarferRat*2a*4 
BASCODE CapTrvnsferRaie3x64 
BASCODE CapTrmnsferSUte4x64 
BASCODE CapTnusferRatteSsM 
BASCODE CapTrasferRate*x64 

6480 BASCODE CapTnuasferRat*384 

BASCODE CapTr*s*fferRAte2a3S4 
BASCODE CapTffusterRaUeJx3S4 
BASCODE CapTranrftfRate4s3S4 
BASCODE CapTrassfcrRateSa3S4 

6485 BASCODE CapTransfcrR*teL536 
BASCODE CeoTrsmtxcxRaUlSttO 
BASCODE CapTrmasfcrRaUUS 
BASCODE CapTranaferRsum 
BASCODE CapTraixsferRate256 

6490 BASCODE CapTtaarferRatteSU 
BASCODE CapTmsferRat«768 
BASCODE CapTraasfcrRatell52 
BASCODE CapTrsmsferRatel472 
BASCODE CapReetrict 

6495 BASCODE Cap 



'0x80000001 
i 0^x80000002; 
■0x 800)000 3 
1 0x80000004: 
1 0x80000005 



.0x80000006: 

■ On 8QO0Qfjfj7 
• 0x80000008: 

■ 0x80000009: 

■ 0x8000000a 

■ OxBOTJOOOOb 
- OxSOOOOOOc 



m A«aQ fjfjrjrjQg 
• 0x8000000f; 
-0x8 000001 0 
■ 0x80000020: 



- 0x80000030 



• 0x80000050 
- 0x80000060; 
1 0x50000070; 



6500 



6505 



//AUDIO CAPABILITIES 
BASCODE CapAudioALaw 
BASCODE CapAttcUofJLew 
BASCODE CapAodioG723 64 
BASCODE CapAndloG722~48 
BASCODE CapAtteUoC728~ 
BASCODE CapAudiolSO 

//VIDEO CAPABILITIES 
BASCODE CapVUeoQCIFI 
BASCODE CapVkdeoQCtT3 



- 0x80000080 



• 0x 80000090: 



- Ox SOOOOObO; 
■ OxBOOOOOcO: 



- OxBOOOOOdO 



• OX 
■OxfiOOOOOfD; 
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6510 



6515 



6520 



6525 



6530 



6535 



6540 



6545 



6550 



6555 



6560 



6565 



6S70 



BASCODE 
BASCODE 
BASCODE 
BASCODE 
BASCODE 
BASCODE 
BASCODE 
BASCODE 
BASCODE 



CapVideoQClF3 

CapVid*oQCIF4 

CapVtdaoCIFl 

CapVftdeoCIFZ 

CapVideoCIFS 

CapVkteoCIF4 

CapVideo improved 

CapVkkolSO 

CapVideaCompacite 



- 0x80000100: 
« 0x80000200; 



//IMAGE CAPABILITIES 
BASCODE CapSuittilPtcturcUmSpccdDaU 
BASCODE f '*pSiimttw^'«~Hith'ip<«f1Diii 
BASCODE CapStnUilPicturtSpatialModc 
BASCODE CapSuatOPicturcPrecnssirrMode 
BASCODE CapSttttiUnctaraAntb«licModc 
BASCODE CapSmttilPtcturcH2al 
BASCODE CapGroapJFax 
BASCODE CapGroup4Fax 

//LOW SPEED DATA CAPABILITIES 
BASCODE CapLow&peadDttta Variable 
BASCODE CapLowSoeedDataJOO 
BASCODE Cap^awSpMdDauUOO 
BASCODE CapLowSpecdDat*4a00 
BASCODE CapLowSpacdDataMOO 
BASCODE CapLewSpccdDataSOOO 
BASCODE CapLawSpatdDataMOO 
BASCODE CapLawSpaadDaial4400 
BASCODE CapLawSpaadDatalaK 
BASCODE CapLewSpecdData24K 
BASCODE f^pi ■ ■ iiiw»wmr_ 
BASCODE CapLawSptadDatadOK 
BASCODE CapLawSpcedData48K 
BASCODE CapLawSpccdDataSaV 
BASCODE CapLawSpeadDataOK 
BASCODE CapLewSpaadDataMK 

// HIGH SPEED DATA CAPABILITIES 

BASCODE CapUighSpcadDattUSK 
BASCODE r^pfH[jiriptmil)trimK 

BASCODE rapHfrhiptnlDitiUnK 
BASCODE ^-pfflthfrpMrinafimK 
BASCODE CapUithSpcadDataSUK 
BASCODE CapHi0aSpcedData7aVK 
BASCODE CapHighSpcadDatallSlK 
BASCODE CapHighSpe«dDatalS36K 
BASCODE r*«|»HfchSpc«<U>iU 

//APPLICATION CAPABILITIES 
BASCODE CapEncryptton 
BASCODE CapGrapfaiciCunar 
BASCODE CapVUOLewSpccdDaU 
BASCODE CapVUGHifhSpeedData 



'0x80000300; 

• 0x80000400: 
•0x80000500: 

• 0x80000600: 
•0x80000700; 
'0x80000800; 
'0x80000900; 



- 0x80000x00: 
-Ox80000b00: 
-OxSOOOOcOO: 
* OxSOOOOdOO; 

- OxSOOOOcOO: 

- 0x80000(00; 

- 0x80001000: 

- 0x80002000: 



• 0x80003000; 
'0x80004000; 
•0x80005000; 
■0x 80006000 ; 
' 0x80007000: 
•0x80008000: 



• 0x80009000: 

• 0x8000*000; 



- 0x80006000: 
m OxBOOOcOOO; 



* OxSOOOdOOO: 



- OxSOOOeOOO; 



•OxSOOOfOOO; 
•0x80010000: 
1 0x80020000: 
• 0x80030000; 



- 0x80040000; 



-0x80050000; 
— 0x80060000; 



• 0x80070000; 
*■ 0x80080000; 



— 0x80090000; 



> 0x800x0000; 
OxSOObOOOO 
— OxSOOoOOOO; 



— Oi800d000Q; 



- OxSOOeOOOO; 



-0x800(0000; 

— 0x 8010000 0; 

— 0x80200000: 

— 0x80300000: 



//MULTIPOINT CONTROL CAPABILITIES 
BASCODE CapSctConfFocus 
BASCODE CapQuefyOmfFocus 
BASCODE CapSctCoafChair 
BASCODE CapQuoTConfChatr 
BASCODE CapAddStattan 
BASCODE CapRcamcSCaxloa 
BASCODE CxpB mad emit Audio 
BASCODE CapBraadcaaVMeo 
BASCODE CapBraadcastData 



(VCO PROPRIETARY) 
m 0x80400000; 



-0x80400001 
-0x80400002; 
-0x80400003 
-0x80400004 
-0x80400005 
-0x80400006; 
-0x80400007 
-0x80400008 
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6575 



6580 



BASCODE 
BASCODE 
BASCODE 
BASCODE 
BASCODE 
BASCODE 
BASCODE 



CapCctNcmSuiioas 

CepGetSlatloaUst 

CapGetStalioaCopf 

CapGctSuttonAocUo 

CapGetStatioa Video 

CapGeiStalionDati 

CapGccSiatioaldcntixy 



• 0x80400009: 

> 0x8O4000Ot 

> 0x8040000b: 



>Ox8040000d 
> 0x8040000e: 



6585 



BIT-RATE ALLOCATION SIGNALS TO SET DEVICE MODES 
(DEVICE MODE COMMANDS) 



// TRANSFER RATE MODES 
BASCODE ModcTw»ferR*te64 

6590 BASCODE ModcTransfcriUt«2x64 
BASCODE ModcTramferRatc3x64 
BASCODE MetfcTrmBs£erRatc4x64 
BASCODE M*deTnuufcrRate5x64 
BASCODE ModeTr*xufcrR*t*6x64 

6595 BASCODE ModeTram#erRaU384 

BASCODE Mod«TratifcrJUU2x3S4 
BASCODE ModeTransftriUle3x3S4 
BASCODE MedcTruxrfcrRat«4x3S 
BASCODE ModcTnmrfcrRatc5x3S4 

6600 BASCODE Mod*Tr*niferRatel£36 
BASCODE Mod*Ti*siferR«Ul920 
BASCODE ModeTnuttfer Rate 128 
BASCODE ModeTnmferlUtelA 
BASCODE MocUTrmnsferiUU256 

6605 BASCODE ModeTramferflatcSH 
BASCODE ModfeTnBtferRaU768 
BASCODE ModtTrxBsfcrR*Uil£2 
BASCODE ModeTran*lerRateU72 



- 0x10000001 
« 0x10000002 

• 0x10000003 

- 0x10000004; 

- 0x10000005 
m 0x10000006; 

- 0x10000007 
"0x10000008; 

- 0x10000009: 

- 0x1000000a: 

- 0x1000000b 

• OxlOOOOOOc 

- OxlOOOOOOd; 

- OxlOOOOOOc 

- OxlOOOOOOf; 

- 0x10000010; 
■ 0x10000020 

- 0x10000030; 
"0x10000040; 

• 0x10000050; 



6610 // AUDIO MODES 

BASCODE ModtAudioOff 1 
BASCODE ModeAudioOff 2 
BASCODE ModeAudioALaw 1 
BASCODE ModeAudioALaw 2 

6615 BASCODE ModeAudioALaw 3 
BASCODE ModcAudioULftw'l 
BASCODE MadtAudJoUL*w~2 
BASCODE ModcAudioULaw 3 
BASCODE ModeAodtoG722 1 

6620 BASCODE ModeAttdioG722 2 
BASCODE ModeAodioC722 3 
BASCODE ModtAodio40K 
BASCODE Mod*Audio32K 
BASCODE ModeAudJoZdK 

6625 BASCODE MsdeAudtof K 
BASCODE ModeAudio64K 
BASCODE ModsAudioUSK 
BASCODE ModeAudiol52K 
BASCODE ModcAudfa256K 

6630 BASCODE ModtAndioWK 

// VIDEO MODES 
BASCODE ModeVtdeoOff 
BASCODE ModtVUeoH26l 

6635 BASCODE Mods Video Improved 
BASCODE ModeVldcolSO 
BASCODE ModeVldeoComposUe 
BASCODE ModeVldcoCIF 
BASCODE ModeVldeoOCIF 

6640 BASCODE ModeVldeo4CIF 

BASCODE ModeVftdcoClF240 



b 0x0000000 1 

- 0x 00000002; 

- 0x00000003; 

- 0x 0 0000004 
™ 0x00000005 
m 0x00000006: 
« 0x00000007 
m 0x00000008 
wm Ob00000009; 
■ OxOQOOOOOx: 



- OxOOOOOOOfa: 
m OttQQOOOOOc: 
■ OxOOOOOOOd 



> O xOOOOOOOe: 



» OxOOOOOOOf; 

■ 0 x0 0000010; 

■ 0x00000020; 
• 0 x0 0000030; 

■ 0x00000040; 

■ 0x00000050; 



'0x20000001 
► 0 t700000O2 



- 0 x20 000003: 
• 0x20000004: 



- 0x20000005; 
• 0x20000006; 



■ 0x20000007; 
> 0x20000008 
• 0x20000009: 
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BASCODE ModeVideoFr 
BASCODE ModtVidcoUnirecst 
BASCODE ModeVtdcoFastUpdate 
6645 BASCODE ModftVkUoDocOn 
BASCODE ModcVfaltoOocOfr 
BASCODE ModtVideaSpUiOn 
BASCODE ModftVideoSpLUOfT 

6630 //IMAGE MODES 

BASCODE ModelSOSuotilPictureLowSpccdData 
BASCODE ModtlSOSootilPictitrcHicfaSpMdData 
BASCODE ModtLowSpccdDaUFtx 
BASCODE ModcHichSpccdDataFu 

66SS BASCODE ModtfPEGLowSpecdDsu 
BASCODE ModUFEGHlfhSpeedDau 

//LOW SPEED DATA MODES 
BASCODE ModtLowSpecdDatiOfT 

6660 BASCODE ModeLowSpcedDal»300 
BASCODE ModeLowSpeedDaUUOO 
BASCODE ModtL»w&peedDat»4I00 
BASCODE Mod«LowSpc«dDmU6400 
BASCODE ftfiHlil pulpta dHiilaHOOO 

6665 BASCODE ModcLowSpccdDataMOO 
BASCODE ModcLowSpc*dDaUl4400 
BASCODE ModcLow5pMdDaUl6K 
BASCODE ModtLowSpttdDsul4K 
BASCODE ModtLowSp«dI>Bft*32K 

6670 BASCODE ModtL*wSpMdDat*40K 
BASCODE ModeLow S pc»dP «to 4IK 
BASCODE ModcL«wSpecdDxla5tfK 
BASCODE ModtLmrSptedDotAfiZK 
BASCODE Mod«LowSpeedD*t«64K 

6675 BASCODE Mod*U>wSpccdD*xaViri*ble 

" HIGH SPEED DATA MODES 

BASCODE M<KfttHichSpe*dDmta64K 

6680 BASCODE h^h^s^— «t yw t » tiyft 

BASCODE ModtHiffaSp*cdDatal*2K 
BASCODE Mo«UHjcfeSpc*dDmta25CK 

BASCODE ModcHighSpccdD»u3B4K 
6685 BASCODE H'^M'f^SpfiMriDat^lTIC 
BASCODE ModcHighSpctdDatrtOK 
BASCODE ModeHigft£peedD8taUS2K 
BASCODE ModtHfehSpccdDBiaiSKK 
BASCODE ModcBifhSpccdDstaVariftUc 

6690 

// APPLICATION MODES 

BASCODE ModeNcuxnl 

BASCODE ModtEncrypciosOa 

BASCODE ModeEacrypUaxtOiT 
6695 BASCODE ModcAisditLoopback 

BASCODE ModeVldtoLoapkwck 

BASCODE ModcRactrtctOn 

BASCODE MocURcstrtctOfT 

BASCODE MaH^ry^^n ^ pR, ^ 
6700 BASCODE MocULoopbickOfT 

BASCODE ModcCompontc^BOn 

BASCODE MedcCompontc^BOrr 

BASCODE ModcCunoiOnLowSpccdDau 

BASCODE ModeFuOoLowSpecdDau 
6705 BASCODE ModtFaxOnUichSpMdDsu 

BASCODE ModeVUQLowSpccdDmta 

BASCODE ModeVt20HlchSp««dData 



1 0x2000000i; 

' 0x2000000b; 

' 0i2000000c; 

• 0*2000000* 
Ox2000000e 
0x2000000f: 
0x20000010: 



' 0x20000020; 
' 0x20000030: 
■ 0x20000040; 
' 0x20000050: 
0 x20000060 ; 
1 0x20000070; 



> Ox 10000001 
0x30000002; 

'0x30000003; 
0x30000004 

'0x30000005: 

' 0x30000006: 



1 0x30000007; 
' 0x30000008; 
1 0x30000009; 



1 0x3000000*; 



> Ox3000000b; 
0x3000000c 



•Ox3000000e; 
* OOOOOOOOf: 



• 0x300000t0; 
< 0x30000020; 



-0x 300000 30; 
* 0x30000040; 



'0x30000050; 
'0x 300000 60; 
1 0x30000070; 
'0x3 0000080 : 
1 0x30000090; 
■ 0x300000x0; 



1 Ox300000b0: 



■ OxTOOOOOcO; 

■ 0x30000040; 



m 0x300000e0; 



» 0x70000060: 
1 0x 20000070;, 
1 0x20000080; 
' 0x20000090: 
■ Ox200000t0: 



1 Ox20 0000c0; 
i OftTOOOflOrtQ* 
1 0x200000c0: 
' 0x200000(0; 
1 0x20000100: 
> 0x70000200; 
' 0x20000300: 
' 0x20000400; 
>Ox2000OS0o! 
* 0x 20000600; 
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PHYSICAL DEVICE INTERFACE HEADER FILE 



6710 



6725 



6740 



6750 



PHYSICAL DEVICE INTERFACE HEADER FILE 
for 

VXRTUAUZED MULTIMEDIA CONNECTION SYSTEMS 

67,5 ABSTRACT 

This source module contains header information used pnnunJy by the server component* tn any Vinuahzed Multimedia Common 
System (VMCSl i mphrflcn a no n. If the special keyword symbol " VCO BUILD" is defined prior to inclusion of this file, it 
indicate* to the compiler that a VCO is being built, and me class "VL" must be defined in full. If this symbol is not defined, it 
indicate* that a VCO diem application ts being built, and only the header files needed so access members of class VDI. and its pure 

6720 virtual device control ovemde member functions m class "PDI". need be considered during the software build process. In this way 
both the server (VCO) and diem components of the VMCS denve symbolic definitions from the same source code base, but no 
vendor-specific (device -dependent) code is at arty dim visible to the device-independent diem appleaoons. 



(SOURCE FILE: PDIM 

PROGRAMMING NOTES 

1. This module contains only C+ source code and structured comments using the " // * noanoa to denote comments (in addition 
to the standard C comment notation using " /■ •/ *). 

6730 2. Symbols defined in dte VDI Software Control Interface are shown tn boldface type below. 

'include < OS.H > // Include opcraung system and user »rf— t API 

« include < BASCODE5.H > // Include bit-rate allocation signal '^^^ 

'include < MCLH > // Include Media Control Interface device conool constants and struca 

6735 'include <VDLH> // Include deruudoa for die VDI and all leas derived classes 

DECLARATION FOR CLASS VL 

dais VL: public VDI { 
protected: 

VUconst char* JniFUe): 

6745 vinual *VL0; 

vinual const char* GetClassNameO { return "VL*; }; 

Jfifdef VCO BUILD 



Vendor-specific special purpose mcmben needed to implement more-derived PDI 
members are defined here. These hineoons must provide all services necessary to 
format dim and control devices in a way consistent with those necessary to best implement 
die ovemdea v> the pure virtual device conoot members in die VDI. 



6755 •/ 
'cttdif 

); 

6760 DECLARATION FOR CLASS PDI 

class PDI: public VL { 
private: 

6765 

// PDI DATA STRUCTURES 



//Perm VCO label string 
char* pVerwon; // Ptr to VCO 



DEVCAPS Local; // Local device capabilities listing 

6770 »nt nModes: // Number of entries m * Modes to Caps" sref iiu 

tm flCaps; // Number of entries in 'Caps m Modes" xref list 

XREF CapsfMaxCapsl; // 'Caps to Modes" xref list 

XREF ModesfMaaModcsl: // 'Modes to Caps" xref list 
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6773 



6780 



6785 



6790 



6795 



6800 



6805 



6810 



68X5 



6820 



6825 



6830 



6835 



const DEVICE 
int 



mt 

conn char* 
MCO BINDING 
HMCO* 
HMCO 



Devices: 

DevfMaxDe vices]; 

nMeo: 

nAudioObj; 

nVidcoObf; 

nlmafcObj; 

nDataObj; 

pMediaLabelQ; 

pMediaBinding: 

phMco: 

hMcofMajtMcoType]; 



// Number of encapsulated devices 

'/ Encapsulated device chain 

// Number of media Ctrl objects currently available 

// Number of audio objects curremJy avaitabic 

// Number of mooon-vtdeo objects 

/' Number of objects 

// Number of data objects 

// Prr to array of ptrs to media Ctrl object labels 

// Ptr to linked list of current media Ctrl object bindings 

// Pit to linked list of all available media Ctrl objects 

// Default media Ctrl object handles 



PDUcomt char* IniFde): 



virtual *PDI0: 

virtual consx char* GetCtassNameO ( return *PDI": }. 

" PURE VIRTUAL OVERRIDES FOR VDI DEVICE CONTROL MEMBERS 
RE5ULTCODE DevOpeal BOOL); MtMBEKS 
RESULTCODE DcvC4oae< BOOL); 

RESULTCODE DevCeanectC CALLPARAM&, STATION*. BOOL )* 

RESULTCODE DevAsawer* CAIXPARAM&Jnt )* 

RESULTCODE DevAfcortO; 

RESULTCODE DevGetCaIUnfo< GALLPARAM& ); 

RESULTCODE V^MtdiaOmtruti MCO.TYPEJ^CO_SETnNG t DWORD,BOOL.BOOL ); 
RESULTCODE DcvEmuCoatroU EMUCONTROLOP ); 

RESULTCODE DevXsstDaUf BYTE*, lot, HMCO. BOOL. BOOL )• 
RESULTCODE DcvRcrDataf BYTE* v lnt f HMCO t BOOL.BOOL ); * 

RESULTCODE DcvSetModesf BASCODE* Jot ); 
RESULTCODE DevSestdCapa( BASCODE*. tot ); 

cows char* DevGctModeLabcJf BASCODE ); 
coast char* DcvCeiCapLabcK BASCODE ); 

MCOPARAM& DevGctMeof HMCO ); 
HMCO DevGetMcoHandle* coast char* ); 
HMCO DcvGetMcoHandle< MCO TYPE ); 

RESULTCODE DevSetDelaiiltMcof MCO TVTE^ooat char* )• 
RESULTCODE DcrSetDcfeiiaMcof MCO~T¥TE,HMCO ); ' 

RESULTCODE DcvSctCeafifff. CONFIGPARAM& ); 
RESULTCODE DevGeiConAtC CONFICPARAM& >; 

RESULTCODE DerSetTuneout* DWORD ); 

RESULTCODE Dev Verify Baud width( BASCODE.BASCODE >; 

RESULTCODE DevIOComrolf IOCONTKOLOP.DWORD.DWORD.BOOUBOOL ); 

" CALLBACK MEMBERS ACCESSED BY PROTCOL STACK AND MAC LAYER 

void far pascal NcrworkEvenrf DWORD EvemCode. DWORD Param ): 

void far pascal DcviceEvemt MC1HEADER* j>MciHcader ); 
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GENERAL VMCS HEADER FILE 

6840 --■-- — --».--.«-..■..■-.«■»„„„ 

GENERAL HEADER FILE 
for 

VIRTVAUZED MULTIMEDIA CONNECTION SYSTEMS 

6843 ABSTRACT 

This source module contains header information used by both diem and server components in any Vinuaiiied Multimedia 
Common System (VMCS) impiemcnuaon, to this way. both the server (VCO) and client components of the VMCS derive 
symbolic defininons from the same source code base. This class serves as a capstone to die VCO class scmcure: so as to present 
every VCO chew with exactly the same member functions a cc ess ibl e from the same class type. The addition of tntpiememaoon- 
6830 specific members to this class can proceed without effecting VCO interoperability or standard VMCS documentation. 

{SOURCE FILE; VCO.H) 

PROGRAMMING NOTES 

6853 This module coiuains only C+ + source code and structured comments using the " // * notation to denote comments t in addition to 
the standard C comment notation using * /* */ 

# include < PDLH > // Include definition for the PDI and all less derived classes 

6860 

/•----..-_-_....-__---- 

DECLARATION FOR ClASS VCO 
-""-------•--•--•/ 

6865 class VCO: public PD1 ( 

public: 

VCO< const char* IniFile): 

6870 

vimtal -VCO0; 

vinuaJ const char* GetClassNamcO ( return "VCO"; }; 

6873 



/• Iniplernematian-speciftc members go here, including members to support : 
...Dynamic link library implcmcnomon 
...Access restncDon for VCO Clients 
...Safeguards against rc-emrancy and otulo- instantiation 

6880 •/ 

}; 
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6883 



6890 



6900 



6915 



6920 



SAMPLE VCO CLIENT APPLICATION 



SAMPLE 
VIRTUAL CONNECTION OBJECT 
CLIENT APPLICATION 
for 

VIKTUAUZED MULTIMEDIA CONNECTION SYSTEMS 
_ ABSTRACT 

«Mfc#M. — , . fc*fw*iB or concurrent media cm cnnnecuom. u c^nnrrri to a defalk immm 
who *c numbers are stored in an uuruiizatum fit* a*—. ... 10 * OCI * uu remote soman 



»»red in an mmaiixaoon file. After successful conKmm >ii mmmiM « ^ 

both the locii and remote snoot* are capable of these onennoni *rv< ^ Z wwy. ror cianry, K u assumed tfut 

(SOURCE FILE: VCOCZJENT. CPP) 
, PROGRAMMING NOTES 

» ^ e C"^^ ~ - ^ ^ ^ ^ - " ' -anon to dene, counts < 
6905 2. Details related to operating system API s, and the ipecifics of the oser interface, nave been emitted for clanry. 
1 t^T^^*^ " VDl Sofnvare Ow/o/ ™ shown m boldface type below. 

6910 < VCO.H > // Include standard VCO Software Control Interface deftittaon 

'define NONBLOCK 0 // Used to set call, to 'non-blocking' mode (urunedtate return) 



Preprocessor macro to create Uhunk" that enables the VCO to t 



> call Notther Receiver Object class members 
mf ' ' * *■ ~ -~* 4 J w* ■* cucen place that has triggered the signal. 

Wefine NOTIFICATION_RECEIVER_MEMBEW.CUss. .Member ) \ 

'define EVENTPROC Noafier«_CUss##,Member< EVENT Id, 

DWORD Paraml. 
DWORD ~Param2. 
STATION* [jpStation. 

6923 ,CUss* pNRO: V HNOTIFIER .hNodfter ) { \ 

rentra ( pNRO ? pNRO->. Member* .Id. .Pararml. .Param2. j>Statxon. JiNoofier ) : 0 ); A 

^ *"* " XPCC,fy V"**™ name to the VCO. such « when creanng 

•/ 

♦define NOTTFICATON_PROC< .Class. .Member ) Notifter##.Class##_Membcr 
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6935 /• VCO Conferencing Object Class used by client apphcanon to esatriish automatic media Ctrl toopoack 

connection id remote station. Logs ill relevero connecoon and media control trace mrarrnanon co a file. Also, 
ail trace m/ormaoon cntanaong from the VCO itself, relating to the operations of the VCO. are displayed (in 
reaJ-arae) on the console display. 

•/ 

6940 class ConfObject( 
public: 

BOOL IsAcbvc: // True if the current session is acove 



6943 



6980 



// Constructor to establish session wuh remote stanon (initiate call, then set toopback) 
ConfObject* VCO& _Vco. char* j>TraceFile); 



// Desmictor ends session wren remote sauon (hangup) 
6930 -ConfObjectO; 



VCOA Vco: // Reference to default VCO for session 

6953 cnar* pTraceFile; // Po* to fUespec for session mce file 

HNOTITTER hNoufyNodfter: // Handle far event noaficanon signal 

HNOTTFIER hDisplayNonfier: // Handle for console message display signal 

6960 // N obiter handling procedure for connecoon and VCO events transmuted to this client class object 

DWORD Notify Proct EVENT id, 

DWORD "Paraml. 

DWORD ~Panm2. 

STA TION* j&waatk. 
6965 HNOTTFTER _tuNotsfier ); 

// NobTter handling procedure to display the VCO teas stream transmitted to this client class object 
DWORD DispiayProc(EVENT M, 

DWORD "Paitml. 
6970 DWORD _Panm2. 

ST ATION* j&XMxkm, 
HNOTIFIER hNorificr >: 

): 

6975 /• Create 'thtuda,* for all the VCO event handling procedures used co direct trigger noofeanons (and text 
messages) to member s in the 'ConfObject* noaficanon receiver object (NRO). 

•/ 

NOTIFICATION RECEIVER MEMBERC ConfObject. NoafyProc); 
NOTTFICAT10N~RECEIVER MEMBERC ConfObject. DuplayProc); 



ConfObject; :ConfObject(VCO& _Vco. char* j>TraceFile) ( 



/• Determine if constructed VCO supports device modes necessary to a conference 
where audio, video, tod binary infortnaoon will be concurrently shared. 

6985 •/ 

LsAcuve — 0: 

Vco - ,Vco: 

pTmccFtle — ^pTraceFile; 

bJ4om>Nodncr - 0: 

6990 nDisplayNooner - 0: 

BOOL CanDoAnrlio - 0; 

BOOL CaoDoVideo - 0: 

BOOL CanDoDao ■> 0: 

DWORD EvenuVUsk - NewRcrMode | NewXmtMode | NewVcoStatc 1 NewCaUStatc: 

6995 DEVCAPS* LocaKTaps - Vco.G«tDevicePanm()Xeps.Local: 
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for ( im i - 0: i < LotilC»pt,nC«p»: i++ »( 
WO * (U SS^SS ( - " CtpVtoQCIFl) " °< vuieo mode ? 

if CLocalCaps.Cap(t] - * CapAudioALaw) // Capable of audio mode * 

CanDoAudjo - I: 

if fLocaJCapi.Capd] - - CapHighSpecdData3ft4K) // Capable of data mode *» 
CaADoOau - I; 

7003 ) 

'* If media cui modes supported, open VCO for usage; 
leup nonficaaora and then inioaltze devices 

•/ 

7010 if (CanDoAudio CanDo Video SlSl CanDoData) ( 

Vco.NcwNotificri hNotify Noofier. 

NOTIFlCAT10N_PROC(Conrc>bjeci. NoufyProc), 

7013 EvcatMaxk ); 

VcoJjiabteNoClflart bDispUyNotifier >; 



7020 



7033 



7040 



7043 



7053 



7060 



Vco.NewNotiftert h DispUy Nodfier. 

MOnnCATTON.PROCfConfObjeci. DisplayProc). 

ftirt 

NcwTermOuSput 



// Activate die sending of VCO messages to the display console 
Vco.AuachTcrmToNotificft hDispUyNodfier >; 
70Z3 Vco.EsMfaleNotifler* hDispUyNotuler ); 



7030 ) 



IiAcave • i : // Mark this session as currently active 

Vco.Opca( NONBLOCK ); // bmaitxe and activate «t«»- r -iE"Hl nb-cystem 



tf Otherwise indicate failure to support operations, and exit, 
j clj * pnntff "Selected VCO incapable of concurrent media cut session. Vn" ); 

ConfDbjecu: XonfDbjectO { 

// If curremty in call, hang it op and output message to trace file 
if ( Vco.UCnUO ) { 

Vco.ToTennmaK "Hanging up call in progress prior to close.Xn* ) 

Vco.H«xicup<): 



Vco.aoacO; it Sundown the encapsulated sub-system (wait until complete) 

If Delete me rionTtcasons 
Vco.DelcteNodfler( hNonfyNodfier Y. 
Vco.DdctcNoclXlefft hDispUyNodfier ); 

7050 pnmfCVCO has been eiosed.\n*>; 

} 



DWORD CoiifObject::DispleyProc( EVENT Id. 

DWORD ~Paraml. 

DWORD ~Panun2. 

STATION* jkSmoon. 

HNOIU1LR _hNodfier ) ( 

} pnnrf( * %xVa * .<chaf).Param2 ); // Display me text message on the console (sid output) 
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DWORD ConfOtojcct::NonfyProc< EVENT _ld. 

DWORD Pinal, 

DWORD ~ Paraml, 

7063 ST ATION* j*S«odo. 

HNOTTFIER hNoofier ) { 



7070 



7073 



7080 



// Process all events dm trigger nodftcatioa 
switch < Jd ) { 

case New Rev Modi: // Log new mode set by remote station 

Vco.ToTerminaU( "Mode Set by RemoteStation f %% ]\n\ 

Vco.GctModcLftbcU(BASCODE) ParamO ): 



; NewXffltMode: // Log new mode set by local itaoon 

Vco.ToTeramaH "Mode Set by Local Soxton ( As J\n\ 

Vco.CetModeiabcU(BASCODE) Paraml) ); 

break; 



case NewVcoSttU: // Handle new VCO sate 

swath ( (im)_Paraml > ( 

case VcoOpta: // Call default remote stauon when opened 

Vco.ToTeraateaU "Successful VCO open: Calling default remote su&oo.tn* ); 
7085 VcoXaW 0. 0. NONBLOCK); 



71 tO 



7U5 



case VcoQose: // Log new VCO close state, men mark session inacdve 

Vco.ToTermmalf "VCO has been closed.Vn" ); 
7090 IsAcnve • 0: 

break: 

case VcoFafltd: // Log VCO error state, then mark session inactive 

case VcoDisabkd: 

7093 Vco.ToTenniiiaU "VCO Error Condition (Ks)\n°. 

Vco.GctVco.Staf 1 jhf l<(im> J>aram I ) ; 

IsAcnve — 0; 

7100 

) 

case NewCaUState: // Handle new VCO call sate 

switch ( (tm) Paraml) { 

7103 case CaniMicnmsrrwd : // Log disconnect of call: end output to oace file: mark session inacove 

Vco .TeTermiaalf "Disconnected from Remote Somen An" ); 
Vcoi>ctacfaTeroaFrocoi TermODevFUc >; 
bAcove - 0; 
break; 



case C aB GimiffUlug; // Begin trace file output: met son of call connection evens 

VeoJUtacJbTermToFQef pTraccFue) : 
Vco.ToTcnxuaaW •Connecting To Remote Somon.Vn* J; 



case CafiCoonected: // Upon connection, uacc formaacd session mformaoon to file 

VcoToTcrnxmal( "Connected to Remote Snoon; Usdng connecnoo daia.\n" >: 
VcolJitrsnPntnO; 
VcoJJstMCOsO; 

// Loop audio, video, an 1 data mput signals back to remote station 
Vco/ToTernusatt "Setting up media cat toopback...\n* ); 
Vrn MtttiaCamtmti Audioln. AoachTo. AudioOut ); 
7123 VcoJSedioCojurcft Video In. AaxchTo. VideoOut ): 

' VcoMtt&aCeturoK Dataln. AnachTo. DataOut ); 
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7130 



break; 

7135 } 



// Set local audio and video (tmc and display) to monitor input s.gruh from the remote teuton 
VcoMrtiaCoiuroH Audjoln. AtnchTo. AudioDst ); — **« 
VaxMediaOmovK Videoln, AnacnTo. VideoOs ); 
break; 



default: 



) 

7140 itonO: 



) 
/* 

7145 •/ 



VCO Client Application to call remote host. Loops back alt audio, video, and data channels when 
wnte* trace of diagnostic session mformason to backing store in reaj-omc. 

X 



// Console* a selected VCO 
7150 MyVco Vcoi •C:\VCOJNT ); 

// Construct the conferencing object 

MyClientApp CoofObjeetl My Vco. 'CAVCO.LOCT ); 

7155 // Block while the connecoviiy session is acchre 

: ( MyClientAnp.lsAcovc ); 
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What: is claimed is: 

1. A multimedia connectivity program residing in 
computer readable memory, said connectivity program when 
executed on a computer providing to an application 

5 program multimedia connectivity services through a real- 
time multimedia device control subsystem including 
components selected from among a plurality of multimedia 
devices and a plurality of real-time multimedia protocol 
stacks, said program comprising: 

io a single binary object encapsulating a virtual 

device interface and a device control interface, said 
virtual device interface including a plurality of virtual 
methods that represent logical operations available to 
the application program for controlling said multimedia 

is device control subsystem, said plurality of virtual 

functions being completely independent of the components 
within the device control subsystem, said device control 
interface mapping said plurality of virtual functions to 
physical control methods which control the components of 

20 the multimedia control subsystem. 

2. The multimedia connectivity program of claim 1 
wherein said device control interface comprises a 
plurality of media control objects which represent 
audiovisual and binary data streams associated with the 

25 components of the plurality of devices and/or real-time 
multimedia protocol stacks. 

3 . The multimedia connectivity program of claim 1 
wherein the virtual device interface is configured to 
present a logical representation of the multimedia 

30 connectivity services provided by the connectivity 
program. 
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4. The multimedia connectivity program of claim 1 
wherein said device control interface comprises a 
virtual i 2 at ion layer and a physical device interface 
layer, said visualization layer located between said 

5 virtual device interface and said physical device 
interface, said physical device interface directly 
interfacing to the device control subsystem to provide a 
physical implementation of services requested by the 
application through the virtual device interface, said 

10 visualization layer residing between the virtual device 
interface and the physical device interface layer and 
configured to translate and map device control mechanisms 
employed by the underlying multimedia control sub-system 
to representations required by the virtual methods of the 

15 virtual device interface. 

5. The multimedia connectivity program of claim 2 
wherein the plurality of media control objects provides 
the multimedia connectivity control program with a pool 
of media device signal resources. 

20 6. The multimedia connectivity program of claim 5 

wherein each of said plurality of media control objects 
is classified as at least one of type of the group 
consisting of an audio type, a video type, an image type, 
and a binary data type. 

25 7. The multimedia connectivity program of claim 6 

wherein each of said plurality of media control objects 
represents a signal from the group consisting of a signal 
from a remote station, a signal to a remote station, a 
signal from a local output device, and a signal to a 

30 local output device. 
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8. The multimedia connectivity program of claim 7 
wherein operations performed on the plurality of media 
control objects by the physical device layer under 
control of the virtual device interface implements a 
logical software switching mechanism connecting incoming 
signal paths to outgoing signal paths, 

9 . The multimedia connectivity program of claim 1 
wherein the virtual device interface implements a 
plurality of public member functions, said virtual 
functions being a subset of those public member functions 
and wherein said plurality of public member functions 
represents all of the public member functions in the 
single binary object that are accessible by the 
application program. 

10. A computer programmed to provide to an 
application program multimedia connectivity services 
through a real-time multimedia device control subsystem, 
the multimedia device control subsystem including 
components selected from among a plurality of multimedia 
devices and a plurality of real-time multimedia protocol 
stacks, said programmed computer comprising: 

a virtual device interface and a device control 
interface, both of which are encapsulated in a single 
binary object, said virtual device interface including a 
plurality of virtual methods that represent logical 
operations available to the application program for 
controlling said multimedia device control subsystem, 
said plurality of virtual functions being completely 
independent of the components within the device control 
subsystem, said device control interface mapping said 
plurality of virtual functions to physical control 
methods which control the components of the multimedia 
control subsystem . 
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11. A computer implemented method of providing 
multimedia connectivity services through a real-time 
multimedia device control subsystem, the multimedia 
device^ control subsystem including components selected 
from among a plurality of multimedia devices and a 
plurality of real-time multimedia protocol stacks , said 
method comprising: 

defining and supporting by computer implemented 
steps a virtual device interface; and 

defining and supporting by computer implemented 
steps a device control interface, wherein both of said 
virtual device interface and said device control 
interface are encapsulated in a single binary object, 
said virtual device interface including a plurality of 
virtual methods that represent logical operations 
available to the application program for controlling said 
multimedia device control subsystem, said plurality of 
virtual functions being completely independent of the 
components within the device control subsystem, said 
device control interface mapping said plurality of 
virtual functions to physical control methods which 
control the components of the multimedia control 
subsystem. 
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CAPABLE OF INPUT MODE 

[GALL ISSTATIONCAP 
FOR LOCAL CAPS USTING1 




YES 



UbltskMINt: IF REMOTE STATION 
15 CAPABLE OF INPUT MODE 

[CALL ISSTATIONCAP 
FOR REMOTE CAPS LISTING] 



CLEAR MODE SUPPORTED 
FLAG {DONNEC11DN 
INCAPABLE OF MODE) 




CUTF\JTTEXTMES5^h 
'CONNECTION jNCAPABLE 
OF MODE" [CALL TOTERMtNAL] 




1 


r 


BET MODE SUPP^TED 
FLAG (CONNECTION CAPABLE 
OF MODE> 


i 


r 


1 OUTPUT TEXT MESSAGE 
'■CONNECTION IS CAPABLEOF 
MODE" [CALL TOTERMINAU 







EXIT! 
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ENTER 
PROCEDURE 
pMJUCOvfTROL] 



CALL CONTROL STATES 

^NUMERATED LINE STATES:" 
[LINEDlSCONNECTEDj 

LINEDIALED] 
LINES US Y] 
'LINERING1 
LlNERINGBACK] 
LIN.ECONNECT] 

[CALLBTATES] 

"ENUMERATED CALL STATES: 1 * 
[CALL D I SC 0 N NECTED] 
C ALLC ON NECTI NG] 
| C ALLCO N N ECTE □] 



LINE Dl! 




NO 



_YES 



NO 



HANDLE DISCONNECT SEQUENCE 
FOR VARIOUS EXISTING CALL 
CALL STATES 
[CALL EXEC LI NED I S C O NN ECTED1 



JO 

r Is" 

TINE RING 
EVENT 

? 

r NO 
IS 

"line rwgbackt 

EVENT 
"NO 

is" 

Tine connected^ 

EVENT 

Imo 

JNE BUS) 
EVENT 

? - 

'no 



HANDLE DIALED SEQUENCE 
FOR VARIOUS EXISTING CALL 
CALL STATES 
[CALL EXEC LI NED1 ALE D] 



YES 



HANDLE RING SEQUENCE 
FOR VARIOUS EXISTING CALL 
CALL STATES 
[CALL EXECL1NERING] 



YES 



HANDLE R1NGBACK SEQUENCE 
FOR VARIOUS EXISTS NG CALL 
CALL STATES 
[CALL EXECLINERINGSACK] 



YES 



HANDLE CONNECT SEQUENCE 
FOR VARIOUS EXISTING CALL 
CALL STATES 
[CALL EXEC LI N ECQ N NECT] 



YES 



HANDLE BUSY SEQUENCE 
FOR VARIOUS EXISTING CALL 
CALL STATES 
[CALL EXECLINEBUSY] 
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ENTER ^\ 
( CONSTRUCTOR ) 



ENTER 
DESTRUCTOR 
[-VCO] 



I 



CONSTRUCT TERMINAL 

EXCEPTION. AIsC 
NT-DISPATCHING CLASSES 
SPECIFIED PARAMETERS 



i 



INmAUZE SYSTEM INFO 
DATA STRUCTURES TO 
KNOWN STARTUP VALUES 



I 



RESTORE INTERNAL . VCO 
CONFIG TOVAUJES IN 

BACKING STORE 
fCALL REGRESHOONFIG 



SEND VCO SHUTDOWN 
TEXT INFORMATION TO 
TERMINAL OUTPUT 
fCALL TOTERMINALV 



i ATTACH TERMINAL OUTPUT 

AND INPUT TO DEFAULT 
iNPUTOUTPUTRLBOEyiCE 
fCALL ATTACHTERMINAL 



3 



START EVENT DISPATCHErV 



OUTPUT TEXT MESSAGES 
SHOWING DEVICeSW 
VERSIONS & CONFK5S 
FOR THIS VCO 
[CALL TOTERMINAL) 



DETACH AND 
DELETE NOTJFIERS 



ATTACHED TO 
VCO DEVICES 



A VCO DEVICE 



ENABLE VCO 
EMULATION MODE 
IF SPECIFIED IN 
CONFIG URATIO N 



I 



VCO EMULATION 

IF SPECIFIED IN 

CONFIGURATION 



START EVENT 
DISPATCHER 



FREE ALLOCATED 
BUFFERS AND 
OBJECTS 



[EXIT] 
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ENTER 
PROCEDURE 
[OPEN] 



VERIFY IF VCO IS 
FULLY OPERATIONAL 
rg&t 1SVGQENIABLED) 



OUTPUT 
"PCI 
(CALLT 





OPEN ALL ASSOCIATED 
VCO MEDIATONNECTION 
DEVICES (CALL DEV OPEN 



SET RETURN VALUE 
TO INDICATE VCO 
DISABLED 



INCREMENT VCO 
REFERENCE COUNT 
(UPDATE RELD IN 
v DEVICEPARAM) 



INCREMENT VCO 
REFERENCE COUNT 
(UPDATE FIELD IN 
x DEV1CEPARAM1 



UPDATE VCO 
CONFIG FROM 
BACKING STORE 
(CALL FESTORECDNHG) 1 




SET RETURN VAWETO 
THAT RETURNED BY 
CALL TO PCI 



RESET AIL CALL PARAMS 
TO DEFAULT UNCONNECTED 
VAUJE^C^RESETCALLI 



RESTORE DEVICES TO DEFAULT 
UNCONNECTED MODES 



[CALL RESTOREDEFAULTMODESt 



.. JTTEXT MESSAGE 
. JEW CLIENT ADDED 1 
(CAUL TOTERMHNjAL) 



SET RETURN VALUE TO 
INDICATE VCO OPEN 
OPERATION SUCCESSFUL 
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ENTER 
PROCEDURE 
[CLOSE] 



VERIFY IF VCO IS 
FULLY OPERATIONAL 
fCALL ISVCOENABLED) 



OUTPUT TEXT MESSAGE 

'•pa&gsEL.y 




RESTORE DEVICE S TO 
DEFAULT UNCONNECTED 
MODEJCALL RESTORE- 
DETAULTMODES'l 



SET RETURN VALUE 
TO INDICATE VCO 
DISABLED 



DECREMENT VCO 
REFERENCE COUNT 



CLOSE ALL ASSOCIATED 
VCO MEDIA/CONNECTION 
DEVICES 
(CALL DEVCLOSE^ 



DECREMENT VCO 
REFERENCJE*pOUPfT 
(UFWTERgBlN 
DEV1GEPARAM) 

CONRG TO BACKING 

STORE 
(CALL STQRECONFIG) 




SET RETURN VALUE TO 
THAT RETURNED BY 



CALL 



OUTPUT TEXT MESSAGE 
"VCVO CONFIG SAVED' 
{CALL TOTERMjNAL) 



I 



OPCl 



OUTPUT TEXT MESi 

"CLIENT 

(CALLTOTERMINAU 




SET RETURN VALUE JO 
INDICATE VCO CLOSE 
OPERATION SUCCESSFUL 



EXITW- 
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ENTER 
PROCEDURE 
[HANGUP] 



VERIFY IFyCOIS 
FULLY OPERATIONAL^ 
(CALL 3SVOQENABLED> 




IS ^-^YES 
REFERENCE COUNT 
NGN-ZERO 



SET RETUFW VALUE TO 
INCHOATE VCO DSABLED 



SET RETURN VALUETO , 
INDICATE VCO NOT OPEN 




T 




SET RETURN VALUE". - 
INDICATE THAT CALL 
MUST BE CONNECTED 




ISSUE CALL.,^, 
CX3MKWC>Tj5Pa 
(CALL DE VABORT) 

3 



1 



SET RETURN VALUETp 
INDICATE RESULT OF 
ABORT COMMAND 
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OPERATION 


DESCRIPTION 




Sat conference focus to specified station 


QueryConFocus . 


Determine identity of station currently in focus 


SetCcnfChair 


Set conference chairman 


QuervConfCbair 


Determine identity of conference chairmen 


AddStation 


Add station to conference 


RemoveStatiori 


Remove station from conference _ 


BroadcastAudto 


Enable or disable broadcasting of audio conference 


Broadcastvideo 


Enable or disable bioaocasfing of video conference 


BroadcastData 


Enable or disable broadcasting of data conference 


"GetNurnStations 


Get number of conferees 


GatStabonUst 


Get tist of conferees 


GetStationCaps 


Get capabiltes of particular conferee 


GeiStafonAudio 


Get audio of particular conferee 


GetStationVideo 


Get video of particukar conferee 


GetStationData 


Get data of particular conferee 


GetStationldentity 


Get numbers and station label of particular conferee 
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